I was reading an interview with Joel Spolsky who writes Joel on Software this AM in the ACM Queue. Much of the time I agree with what Joel has to say, but something he said in the article really rubbed me the wrong way.
He was going on and on about how there isn't any real science in all the software engineering books and articles. Things like programmers having offices being based off of one weekend study done years ago and simply parroted by others over time. While he is right to say that the software engineering texts aren't giving us the best advice, he is very, very wrong to say that we don't know anything about this.
Every time I watch a large construction project or watch a show on TV about how some huge project was done and that it is either ahead of or behind schedule, I know that those projects face exactly the same kinds of issues as software development.
Someone changed the plans again, or the welds on the beams from a supplier are failing. We just released a product to manufacturing yesterday. It was quite a successful project so far, hopefully it sells well when it hits the stores. It was a project that had a very tight and short schedule due to a hard deadline.
While we pulled it off there were several things that occurred along the way that were classic problems for any business. At one point someone suddenly realized that one of our key people was going to be on vacation for a week and all of a sudden the whole project slipped.
This actually resulted in us devoting more time to development which made for a better product. However, it would have been an even better product if we hadn't switched gears in the middle. The new features that were added had a domino effect of requiring a user interface redesign. If we had known we had more time to start with we could have planned the UI better and most likely would have had time for another feature or two.
We also had last minute problems due to a misunderstanding about how we needed to branch our software to avoid problems. This resulted in a lost day due to a failed automatic build that occurred because of the side-effect of fixing an entirely unrelated bug in another product that is only loosely related to the failed product. Lesson learned.
The point of all this is that every complex project out there works under the same fundamental principals. We are dealing with people of various skill sets and they make mistakes. The projects that are completed on time are the ones with the best managers that understand principals of time management and anticipate the unexpected by putting time into the schedule for these items.
The software industry could learn a lot from the construction industry in the area of project management. Certainly, there are differences in specifics. It's a heck of a lot easier to change a broken foundational class than it is to fix a badly poured concrete foundation in a building. The ramifications of the change in the software and the resulting issues in the building can be far reaching. It's way better in both cases to get it right at the start.
Because it seems so easy to change the design of the software at any point along the way, we can get complacent about building things well. The problem is later on you have all of these things that adapt to the bad design and in a sense come to depend on it. When you go back months or years later and need to fix the bad design you are also faced with needing to identify and fix all the places that depend on it. Faced with an impending release date you may end up opting not to fix it and add yet another band aid fix that makes fixing it next time around even harder.
In any case, the next time someone says we need to study the problem of software engineering more, or that there is no science that helps us do this, slap them soundly and point them at the nearest large construction project.
No comments:
Post a Comment