Measure twice, cut once!

Dennis Lowary's Log Book entry presents a case study of programming in the small (one person) on a short duration project. He tried to use some software estimation and requirements techniques but abandoned them early, because he felt it was too much overhead for the project. In the end, he felt the project did not turn out quite like he intended and wondered if he too hastily abandoned a software engineering discipline.

There is an old carpentry saying, "Measure twice, cut once!" Meticulous attention to upfront detail makes the project go easier. What carpenters knew centuries ago is great advice for us, but does current software engineering practice "scale down" to small projects or do we need to revise them significantly? What do you think or, better yet, what have you experienced? One thing is sure, we need more case studies and data to understand what does and does not work! Later!

Dennis Lowary's Log Book entry:

My entry is about thoughts I had while working on a recent project.

Courses like this focus on projects of long duration (months and years of work for a group of people). Can the theories discussed be applied to situations that are significantly smaller in magnitude? What should/could be done under the following conditions:

You’re told: “Create a database-driven website of some useful functionality”

You have:

* 14 days starting now

* A single-person staff (yourself)

* Very limited, or no experience with the languages you must use

* No advanced tools

With such a short time frame, is it possible to apply anything discussed in this course such that it is a

benefit? This was something I considered recently while working on this project. After choosing an overall function for the site, I attempted to create a set of requirements. Part of the deal was I had to state specific aspects of the intended functionality and once stated they had to be completed. I needed to not make it too simplistic, but a big concern was not to say I would do something that I couldn’t. I don’t have an enormous amount of experience with coding, but I have enough to know that something I might think simple on paper may be unforeseeably difficult to implement.

I considered trying to create some sort of ranking system for the possible features so that I could decide which ones to commit to. After doing that for about 5 minutes, I thought “What am I doing? I can’t worry about this that much; there isn’t enough time.” So I ended up putting very little thought into what it might take to implement each one and just picked some that seemed easy enough to be attainable. My hasty rough estimates were not good. I had a very hard time getting everything working on time, and what did work was either ugly to look at, ugly from a logical point of view, very not user-friendly, or a mixture of those things. I have to think that not doing any (in-depth) type of metrics or estimation that I saved time that I (apparently) needed to get the thing to the barely usable state that I did. On the other hand, I wonder if I spent more time on estimation, could it have possibly come out better. I certainly understand that it would have with a large scale version (larger staff and time frame) but with such limited time and resources is it possible at all?