Undertaking Projects

So I read a post from a friends blog, “Working Small”, and after I read the quote from Linus Torvalds in it I decided it was time to argue points.
Well, the next day at work we talked about the quote because I was curious about perspective on it and it seemed that we both agreed. What we both took the quote to mean was that looking at a project can be a very daunting task. Taking it from start to finish while meeting requirements, fixing bugs, working with new technologies, etc. is quite complicated. However, what we concluded is that the quote really depicts a view on how to go about working on these kinds of projects.

First you must understand that projects for clients are going to need to be thought out, put into a timeline, and then worked on until completion. However, what concerns me is the working on until completion part…thats the portion I do. If you start out by taking some project and work on it’s entire architecture and _then_ begin to develop it, you may have problems.

One of the problems, and possibly the worst, IMO, is the lack of agility. You will have a much more complicated time restructuring a system if you go through the architecture in advance of any of the development. Instead, if you focus on smaller tasks you will have a better idea of the start and end points and be able to develop with a clear vision in mind. Also, you have more ability the change an API or develop new ones as you are developing it due to certain needs. You are less likely to be able to change due to clients needs. Many projects go for some period of time and due to this, requirements may change. The client may decide over that period of time that the functionality of requirement ‘x’ actually needs to do ‘y’. In a hard fast architecture you have 0 agility. Instead, you need to add more to the application which creates bloat and functionality that may not be used. This leads to the inability to refactor your code effectively without leaving broken windows.

Now, these ideas are not new. The guys over at the Pragmatic Programmer have been talking about it for some time, however, I thought that the quote was the common link between what those guys are saying. It really embodies the view most developers should have when undertaking a project. While some architecture is important, it should not be the entire focus of the initial stages of development. There is something to be said about building prototypes and hashing ideas out before really designing the architecture of the final product.

You must have some idea of where you want to go, but that does not mean you should throw agility and prototypes out of the window.