A day after Mountain Lion came out for the Mac, I upgraded. It works great and I am very happy with it. If you noticed, Apple didn't let anyone know the exact release date, until the day before it was released. We still don't know when iOS 6 will be released by Apple - only that it is coming out sometime in the fall. This is now the norm with software vendors.
When I was getting my graduate degree in CS, I spent a lot of time thinking about software complexity, which was the subject of my master's thesis and project. I built a cool software model around AJ Albrecht's work for measuring complexity called Function Points.
Software complexity is important, because understanding complexity helps you understand how long it may take you to build something. If you know that a software system has say, n complexity, before you start building it and you know how long it takes to build something of n complexity (based on historical data), then you know how long it takes to build that software system.
The fundamental problem is that you never really know upfront how complex a software system is, and hence how long it will take you to build. This is something that people with production-minded backgrounds have a really difficult time getting their minds around. It's not like manufacturing printers or building houses - software is not constrained by the laws of physics, has many more moving parts, and can be changed at the very last minute. As a matter of fact, in a good software development process, you delay as many decisions as possible - because you are always learning things as you are putting product together. Some people say developing software is more like writing a book or producing a movie, and that sounds about right to me - you can and should change things at last minute, as long as you understand the costs.
Also - the larger the project, the bigger the estimate risk. I personally like breaking up large projects into smaller deliverables, which gives you insight on how well the product development is going. In our current product, I like (and use) two week sprints and 10 week release cycles. That means that every 10 weeks we deliver new product like clock work. If something will take more than 10 weeks, we break it up so that deliverables fit into that window. If a 10 week release cycle deliverable it not useful to the end user, we keep it in-house - but interestingly that is rarely the case. We can usually find value to deliver every 10 weeks.
A time-constrained release cycle also gives you a time box for delivering value. Many times we will constrain the delivery of a feature to a release cycle. This forces us to make decisions about what is really import. There is a lot that can get left behind, but we often find those things were not that important.
It also really helps to have senior software developers with deep experience. Nonetheless, it's non-trivial to estimate how complex a software system is before you build it, but if you break up your product into small deliverables, and time constrain those deliverables, you have a good chance of hitting delivery estimates.
No comments:
Post a Comment