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?

Can Open Source become too popular?

In his Log Book entry Lucas Vickers discusses his experience with Open Source support and contrasts it with his experience with Microsoft support. He also poses an interesting question at the end, thqat as more folks use Open Source the expertise level will go down and more Open Source developers will be bombarded with newbie questions. Do you think this will happen? If so, how can Open Source developers handle the support demand?

As an added bonus in his Log Book, Lucas gives us a pointer to another rule base language, Drools. In a later blog entry I will give you my impressions of the Drools tool. Later!

Lucas Vicker's Log Book Entry:

Open source is the topic of this week’s discussion, and it is something that I am fairly interested in. I have worked with open source products, and I have also worked with Microsoft products. I know using Microsoft as the model for what comes out of corporate development is a little unfair; however I am going to do so because I have the most extensive experience with them. To be honest I have found Microsoft products that work really well, and I have found open source products that work really well. I once developed a program for the pocketPC platform using Microsoft tools, and oh my that was one of the buggiest platforms I have ever worked with (this was back in 2002). I have also recently tried to integrate Drools, an open source and java based rules engine. After a few weeks of heavy coding with Drools I found that there was a major flaw in the implementation which halted my work. What I am trying to say is that each product has its flaws. The difference is as soon as I had a problem with drools, I sent off an email to the developer, met him on IRC on #drools, and we resolved the problem with in a few days. Any problem I had with Microsoft all I could do was search MSDN and pray that they have an answer to my question. I think that one major factor to consider is the group of developers behind a project. Open Source developers really love what they do, work in their spare time because it’s a passion, and are very easy to contact. Microsoft developers, however, hide behind the veil that is Microsoft and it is near impossible to get an explanation for why a function works a certain way. I think knowing that OS developers are developing because they want to and love to, and are accessible, gives open source software an edge. I wonder if this edge would disappear once the average user began attempting to use OS software and the developers became flooded with repetitive and useless questions.

Catch-22

The following entry from Kaylon Daniels begins a series of entries from my summer software engineering class. It seems that every semester, outsourcing becomes a larger issue with the graduating generation of computer scientists. Kaylon's entry discusses the effect it is having in this country and speculates on the long term effects. A later entry in this series will discuss some other aspects of outsourcing and its effect on quality. I would appreciate any comments on this post or your views on outsourcing, its effect and potential opportunites outsourcing may provide.

Here's Kaylon's Logbook entry.

Most of my log book entries have been relatively short. But this one will be one of my longer posts. I just wanted to write some of my thoughts and discoveries about outsourcing. This is an important topic to me because I am unemployed at the moment and have been wondering how much of the credit I can assign my employment status to this phenomenon. I’ve read some articles in Business 2.0 and Business Weekly and I’m unsure which opinion to believe. Biz 2.0 states that outsourcing is going to have long term positive impacts on the U.S. economy. The middle class in other countries can afford to purchase our goods; this will produce more jobs in the U.S. They also feel that it frees Americans to pursue more advanced technologies while low level maintenance work is passed on to the third world. Now, Business Weekly states that outsourcing has nothing to do with the low level of tech jobs available. They state that the U.S. worker has been undone by his/her own productivity. Because the American worker can do more with less, there is less of a need for skilled workers. Maybe they are both correct to some extent, but I am sure of one fact. The last job fair I attended, I waited in a line that went around an entire city block. I couldn’t believe what I was seeing. This country is beginning to resemble Brazil more every month. Outsourcing is just another blow to the middle class which is already starting to disappear. Personally, I haven’t seen another tech industry pop up to replace dot-com businesses. There has been talk about nanotech and commercial space goods, but how can we capitalize on these markets when very few Americans are actually studying sciences. Most students in these fields are from nations we are currently outsourcing to. These emerging countries should be able to produce enough capital (thanks to a growing middle class) to research these new tech fields; why would one assume that the U.S. will have any real influence on the next generation of technology. It seems to be a catch-22 situation.

End of logbook entry. Before I end this post, a brief interlude on the phrase Catch-22, which defines a can't win situation. Catch-22 was written by Joseph Heller and Alan Arkin starred in the movie in 1970. It concerned World War II bomber pilots. Orr was pilot who was trying to get grounded by reason of insanity. The defining moment in the book is captured in this quote:

There was only one catch and that was Catch-22, which specified that a concern for one's safety in the face of dangers that were real and immediate was the process of a rational mind. Orr was crazy and could be grounded. All he had to do was ask; and as soon as he did, he would no longer be crazy and would have to fly more missions. Orr would be crazy to fly more missions and sane if he didn't, but if he was sane he had to fly them. If he flew them he was crazy and didn't have to; but if he didn't want to he was sane and had to. Yossarian was moved very deeply by the absolute simplicity of this clause of Catch-22 and let out a respectful whistle.
"That's some catch, that Catch-22," he observed.
"It's the best there is," Doc Daneeka agreed.

If you would like to discover more about Catch-22, check out this site, where I refamilliarized myself with the book. It is a great book that was very popular in courses when I was in college in the late 60's, early 70's.

Later.