Microsoft Surface Tablet

So, the Microsoft Surface tablet is the gadget that I’m most excited about seeing.  It is Microsoft’s entry into the tablet market currently dominated by the iPad and various Android devices.  I have had my Kindle Fire for about a year now and am beginning to realize just how useful a full fledged tablet can be.

However, in contemplating the purchage of a Microsoft Surface Tablet, I have come up with a list of things that must be supported on the device in order to make it useful for me:

  • Email – This is a given, it will be there.
  • Web – You know Internet Explorer will be there.  However, I would need to make sure it supports the video lectures posted on OSU’s Desire2Learn site in order for it to be useful for me.
  • Office – Again, this is a given.  What remains to be seen is how good the keyboard is.  Can I realistically write an entire paper on it? Or would I find myself going back to my laptop?
  • Dropbox – This is critical to the way I work.  I store all of the documents for projects and classes I’m currently working on out there so that it will sync between the various computers and devices that I use.
  • Evernote – This is also critical.  I have bee using Evernote for years as a way of keeping track of information and notes and, like Dropbox, letting it sync beween my devices.
  • Amazon Kindle – I have a large investment in Kindle books that I currently read with my Fire.  It remains to be seen how much I would read on a full tablet vs. the Fire, but it is critical that the tablet allow me to download my books.
  • Amazon Cloud Player – Like the Kinde books, I also have a ton of music stored out on my Amazon Cloud drive.  This really is more of a nice to have, because I’m sure I could download music onto the device.  However, being able to play them directy from the cloud would be very nice.

And then there is the price.  The Surface has to cost less than $500 to make it attractive.  That’s the price of the iPad.  If this isn’t at that price or below, it will be a flop and I wouldn’t buy it.

I’m pretty sure I will be purchasing a tablet within the next 6 to 12 months.  Will it be a Microsoft Surface?  I’d like it to be.  But, that remains to be seen.

Tulsa Tech Fest 2010 – Domain Driven Design

Today I will be giving a presentation on Domain Driven Design at Tulsa Tech Fest 2010.  If you work in IT in the Tulsa Area you really ought to try to come out.  There is going to be a ton of presentations and the event is completely free.

My slide deck:  Domain Driven Design – TTF10 – Matt Peters

Example code:

Tulsa .Net Users Group: The 7 Habits of Highly Effective Developers

I’m giving a presentation tonight at the Tulsa .Net Users Group titled The 7 Habits of Highly Effective Developers. Sure, a developer needs to be a good coder. But, in reality that is a very small piece of their job. In this session we’ll discuss some of the other skills and habits that developer should concentrate on in order to be successful.

You can download the slide deck here.

And here are links to the blogs, podcasts, and books mentioned in the presentation:

New Legacy Christian School Website

Last week we went live with a new version of the Legacy Christian School website.  Check it out and let me know what you think.  I built this using Element Fusion’s SkyCMS.  Element Fusion is a great company out of Oklahoma City that I have worked with on a number of websites.  I highly recommend this CMS.  It’s comes with many templates that are easy to customize, and it’s very easy to create your own templates as well.  Content management is also a breeze through this CMS.

One of the most important things when building a website like this is ease of content management.  It’s almost better to not have a website than to have a website with stale content.  If it’s easy for the customer to go in a add content than they are more likely to keep it fresh.  SkyCMS makes this very easy.

Qualities of a Good IT Manager

In my career, I have worked for and observed a wide range of managers. Some are great, some are less so. But, as I’ve made the progression into management over the last couple years, I have thought a lot about what makes a good manager in IT. Perhaps these apply to other fields, but IT is the one I have the most exposure to, so that is all I can speak of.

Accept the responsibility, share the credit

This first one deals mainly with how achievements and failures by the team as a whole are looked upon by those outside the team. It is a hard one for many managers.

If you and your team do well, a lot of times upper management will praise you. They may be completely unaware of the hard work that your team put in. Be sure to share the credit for the achievement with your team. One of the quickest ways to lose the respect of your team is the accept the credit for what they have done for yourself.

But, on the other hand, if something goes wrong with a project, the manager needs to accept the responsibility for the failure for themselves. Upper management never looks well upon a manager who blames problems on their team. And you’ll gain the respect of your team if you accept the responsibility (at least to those outside the team) for yourself.

Reprimand in private, praise in public

This next one deals with individual achievements or failings of someone on the team. If someone on your team really messes up, never reprimand him or her in front of the other team members, and certainly never in front of people from other teams. I’ve seen this done before and it’s the quickest way to lose my respect. If someone messes up, pull them aside and talk to them privately, where others cannot hear. Discuss what they did wrong, why it was wrong, and what they can do to do better in the future.

However, on the flip side, if someone does an outstanding job, praise him in front of the rest of the team. The team needs to know the hard work and achievement are rewarded. They’ll strive for this recognition themselves.

Know your stuff, but listen to your team

Within IT you have managers with strong IT backgrounds, such as those that use to be programmers themselves, and those without this background. In my experience, the best managers are those that have the background and really know their stuff. However, if a topic comes up that the manager is not familiar with, he or she must be willing to admit that they do not. I have know managers that try to pretend they have the depth that they do not. This is another quick way to lose the respect of your team.

But, as a manager, you have a team. And part of your responsibility is the hire good people. And, if you hire and pay for good people, you would be foolish not to listen to them when they are speaking from their own expertise. A manager must always be willing to listen to his or her people. There are times that you have to stick to your decisions, but you team must feel like they were at least given a voice. But, as often as not, someone on your team will have a better idea than you do. You must be willing to listen to them and have the humility to admit that they are right.

Hire and empower the right people

This is a big one, and I’m pretty sure I’m going to devote an entire post on how to hire the right people. As a manager, you are not doing everything yourself. Most of the time you cannot possibly do everything yourself. You must be able to delegate tasks and responsibilities to your team. And they only way you can do this and be successful is if you hire the right people.

But, just hiring them isn’t enough. After you have hired them, you must empower them. Be able to delegate responsibilities to them and trust that they are going to do a good job. By default, do not micromanage. I have had people on my team in the past that I have ended up having to micromanage, but they were definitely not the right people and should not have been on the team to begin with. The only way to stay sane in management is to be able to delegate to your team and trust them to do a terrific job.

Have the confidence to make the hard decisions

A big part of management is making the hard decisions. These are the decisions where the long term results are unclear and the wrong decision could potentially be disastrous. Collect all of the information you need. Determine if a decision needs to be made. If it needs to be made quickly, trust the input from your team and make the decision. A lot of times problems are made worse because decisions are not made in a timely manor.  These managers lack the confidence in their themselves and their team to make the decisions. If the decision ends up being wrong, have the guts to admit your mistake and move on.

Conclusion

Management is hard, and it can be very stressful. But if, as a manager, you would follow the basic principles I have outline above I’m confident that you and your team will be successful and you’ll win the respect of your team and your peers.

Software Project Estimation Part 9: Conclusion

In the previous posts I have discussed the process of software development so that we can get a good handle on what we are estimating.  I have discussed the cone of uncertainty so we can know how accurate our estimates should be.  And I have talked about four different estimation techniques: Expert Judgement, Count, Function Point Analysis, Story Points, and Decomposition.

So, you may ask, which estimation technique is the best?  And my answer would be, as in so many things, “it depends”.  If you are very early in the project, and have team members with a lot of experience in the environment and good historical knowledge of projects in the domain, Expert Judgement will be a good choice.  If the project will have components that are easily identifiable early in the process, then Count is good.  If you are doing a pure Agile project and your schedule can be a little more fluid, then Story Points will work for you.  If a detailed design has been completed, Decomposition is good.  My favorite estimation technique, though, is Function Point Analysis, which can be executed at any stage in the project.  But you must have a counter with experience in the technique.

The best plan, though, is to become very familiar with all of these techniques.  You can then have these tools in your back pocket that can be pulled out and used on any project, depending on the unique nature and needs of the individual project.

For more information on the subject, I highly recommend reading the book Software Estimation: Demystifying the Black Art by Steve McConnell.  This book does a good job of going into detail on each of these techniques and several more.

Thanks for joining me as I worked though this series.  This is a topic I’m passionate about.  I hope that reviewing these techniques has helped you out in your own projects.

Software Project Estimation Part 8: Decomposition

Decomposition is the estimation technique most software developers are familiar with.  Using this technique, you break the entire project into the individual components that are going to be impacted.  Within each component, you itemize the changes that have be be made.  You then estimate how long each of those changes will take to complete.  Add up the changes for a component and you have the estimate for the component.  Add up the components within the project, and you have the construction estimate for the entire project.

There are a couple of issues with this technique.  The first problem is that it requires a detailed level of design knowledge concerning the project to come up with an estimate.  If you are in the early stages of a project, you aren’t going to know all of the components that must be modified.  And if you don’t even know the components you certainly aren’t going to know the changes within the components.

The second issue is that you have to know the skill level of the person doing the work.  If you have a rock star developer doing the coding, then the estimate should be significantly different then if you have a new hire.  In order to put together this kind of estimate you need to know who is doing the work.

But, this level of estimate does have its place.  It just needs to be utilized late in the project, after technical design has been completed and you know who is going to be doing the development.

Software Project Estimation Part 7: Story Points

This post is part of my series on Software Project Estimation:

Story Point Estimation is the most popular form of estimation on projects using Agile methodologies. Using this technique, you begin with all of the User Stories, or Use Cases, for the project. Then a number is assigned to each of those stories to indicate their relative size. Normally, this number is from the Fibonacci sequence (1, 2, 3, 5, 8, 13, etc.) or a power of 2 (2, 4, 6, 8, 16, etc.).

When the numbers are first assigned, they are not given a unit of measure. That is, a User Story that is assigned a “2” does not necessarily take 2 hours or 2 days to complete. The numbers are assigned based on the estimated size relationship between the User Stories. That is, if User Story 1 is assigned a “2”, and the team decides that User Story 2 is around 50% larger that User Story 1, User Story 2 will be assigned a “3”.

Once all of the User Stories have been assigned a number, the team will decide what they thing their starting velocity will be. They may decide that they can complete work on 20 Story Points per 2 week iteration. The User Stories to be completed during the first iteration will be determined based on this Velocity. Project Management can also use this velocity to project when the entire project will be completed.

After each iteration, the actual velocity will be computed to determine if the number of Story Points per iteration needs to be adjusted up or down. Based on this adjusted velocity, management can determine if they need to push out the end date of the project or remove User Stories from the scope.

Story Points is a great estimation technique to use in Agile development where you aren’t expect an precise estimate.  It gives you a tool to measure how the work is progressing and to project when the work will be complete.

Software Project Estimation Part 6: Function Point Analysis

This post is part of my series on Software Project Estimation:

Function Point Analysis is one of the estimation techniques I have been most excited about over the past few years.  It’s actually a specific implementation of the “Count” methodology that I talked about prevoiusly.  But, I figured it was important enough to give it it’s own post.

In Function Point Analysis you count the number of Function Points in a project.  To get there, you first have draw a boundary representing the scope of your project.  You then make an inventory of all of the interfaces (data in motion) and files (data at rest) associated with the project.

There are 2 different types of files that have to be identified:

  • Internal Logical File (ILF): A file whose data is created and maintained by this application.
  • External Interface File (EIF): A file whose data is referenced by this application, but not maintained by it.

For each one of the file types you have to count the number of record element types (tables) and data element types (columns within the tables).  Based on these counts, each file is assigned a number of Function Points.  The important thing with these files is to keep in mind that they might not actually be a database or a file.  They could be something like another system that is interfaced with.

There are 3 different types of iterfaces that have to be identified:

  • External Inputs (EI): Data coming into the system from outside the system.  An example would be a user’s login form.
  • External Outputs (EO): Data coming out of the system from inside the system. An example would be a report.
  • External Inquiries (EQ): An interface where some data comes in which causing processing and then some data coming out.  An example would be a search form.

For each of these interfaces, you have to identify the number of record file types that are interfaced with and data element types that are carried along the interface.  Based on those counts, each interface is assigned a number of Function Points.

Once you have identified the interfaces and files and assigned a number of Function Points to each, you can add up those counts and come up with your Unadjusted Function Point count.

The Global System Characteristics can then be used to adjust this Function Point Count.  The Global System Characteristics are attributes used to assess the complexity of an application.  Once you assign a rating to each characteristic, you come up with an adjustment factor.  It may be something like 1.1.  You then muliply your Unadjusted Function Point Count by this adjustment factor to get your Adjusted Function Point Count.

At this point you just have a number which is pretty meaningless on its own.  However, industry standards exist showing, on average, how long it takes application development teams to complete projects of different Function Point counts.  In my experience doing .Net projects, I know that it takes about 15 hours per Function Point for coding and unit testing.

This will give you the hours for development.  The percentages assigned to each phase of the project can then be used to determine how long the entire project will take.

It’s very easy to learn the basics of counting Function Points.  Becoming an expert, however, takes lots of study and practice.  If you give the same project requirements to two different expert counters, their counts will come out almost identical.  This makes Function Point Analysis a very useful methodology for estimating the size of a project.

foursquare vs. Gowalla vs. brightkite: The Location Based Social Networking War

Ok, so for the last couple weeks I have been using three location-based social networking tools, trying to determine which I like best.  The contendors are foursqure, Gowalla, and brightkite.

First, let’s talk about the concept.  Using these tools you “check in” at locations you visit.  Seems like a neat way to see what your friends are doing and find interesting places to go and things to see.  Each of these tools will post to Facebook and Twitter so all of your followers on those services will see updates.  And each of these tools have great iPhone apps.  The problem is that they each of great features, and several shortcomings.  So, I’m having trouble picking one.

foursqure

Foursqure is the most popular of the three.  I love the concept of becoming a Mayor of a location and collecting Badges.  But, it doesn’t give you an easy way to see on a page what your friends are doing, or who is currently near you.  Both of these seem obvious features that I just cannot find on their website.  Actually, on the home screen of the iPhone app you see where your friends currently are, but I cannot find it anywhere on the website.  However, the majority of my friends using one of these tools is using foursqure, so that is a plus for it.

Gowalla

Gowalla is the next most popular.  Unlike foursqure, on the Gowalla home page you can easily see what your friends are doing.  It also has the concept of Creators and Founders, which seems very similar to the Mayors on foursquare.  I love the large locaiton icons it uses and the stamps you earn and items you can drop.  Gowalla was really looking like it would come out in first place for me, but it does something strange with the Twitter posts.  When it posts to twitter it seems to insert a random “@” username in for the location name.  I can’t find on the locations where these twitter usernames are set.  Seems like a pretty major bug to me, so I don’t think this is going to be the one I end up using.

brightkite

Brightkite is the least popular of the three, but surprisingly the most feature rich.  You can easily see people near you at any radius you select.  You can also easily see what your friends are doing.  It also gives you the ability to upload a picture when you checkin.  You can set it up to automatically push that picture to Flick or your Facebook photo album.  It doesn’t seem to have any concept like a Mayor or Founder.  But that’s not a huge deal.  Really, the biggest downside for me on brightkite is the fact that I only have a few friends on it, and almost all of them have switched exclusively to foursqure or Gowalla.

So, in my personal opinion, brightkite should win the war of the location based social networking tools.  Do I think it will?  Probably not.  Foursqure and Gowalla are currently much more popular.  But brightkite is the most feature rich and seems the most stable.  So, everyone out there who is looking at these tools, let’s all switch to brightkite and call this war over!

If you are using any of these three, add me as a friend.  Here are the links to my profiles: