<body><script type="text/javascript"> function setAttributeOnload(object, attribute, val) { if(window.addEventListener) { window.addEventListener('load', function(){ object[attribute] = val; }, false); } else { window.attachEvent('onload', function(){ object[attribute] = val; }); } } </script> <div id="navbar-iframe-container"></div> <script type="text/javascript" src="https://apis.google.com/js/plusone.js"></script> <script type="text/javascript"> gapi.load("gapi.iframes:gapi.iframes.style.bubble", function() { if (gapi.iframes && gapi.iframes.getContext) { gapi.iframes.getContext().openChild({ url: 'https://www.blogger.com/navbar.g?targetBlogID\x3d6566853\x26blogName\x3d1%25+inspiration\x26publishMode\x3dPUBLISH_MODE_BLOGSPOT\x26navbarType\x3dBLUE\x26layoutType\x3dCLASSIC\x26searchRoot\x3dhttp://patke.blogspot.com/search\x26blogLocale\x3den\x26v\x3d2\x26homepageUrl\x3dhttp://patke.blogspot.com/\x26vt\x3d8220196945898414734', where: document.getElementById("navbar-iframe-container"), id: "navbar-iframe" }); } }); </script>
Archives
Subscribe


Tuesday, September 07, 2004

I hate deadlines.

Not because of the connotations the word "deadline" invokes from all of us: stress, hard work, conflict, etc. But because of the effect of deadlines on the product.

Software development is a trade-off between time, money, and quality. A deadline is purely a restriction on the "time" aspect of this trinity. ...but what other kinds of restrictions are there? Money is the obvious restriction. In fact, this is the restriction which ultimately effects the deadline.

What I am working at is trying to find a "quality restriction". Nobody ever considers the quality effects of their decisions. Quality is discussed purely in terms of "feature completeness" and "customer satisfaction". But quality software involves so much more. As a simple example, I wrote a program last week that executed some basic File IO operations. Took about 3 hours. Yesterday, I rewrote that program to accept parameters from an XML file such that the XML file determined the operations to be performed and stored the parameters necessary for those operations (similar to ANT). This rewrite took about 6 hours. So, total development time was 9 hours, even though the program was feature complete in 3. So the project was 3x over budget! But instead of having a program that can only be used once for a very specific purpose, I have developed a program that provides a pseudo scripting environment for the Pocket PC.

To me this raises a few questions. First, if this kind of thing happens on small projects can it happen for a large project as well? From my experience - certainly. Large projects are more complicated versions of small projects. Any problem or oversight that can occur on a small project is likely to be amplified on a large project.

Second, since the first program was "throw away", why was it written at all? Basically I didn't fully understand the problem before I began writing the software. I saw the problem as a need to move files as opposed to a need to provide a scripting language. This was due to poor planning on my part. However, this kind of "requirements discovery" is quite common on projects - but highly frowned upon. But let me ask you this: You are a mechanic and looking at an engine - while fixing the clutch you find a crack in the "something". Would you continue to fix the clutch because the other something is not what you were hired to do? Or do you take some time to fix the other something as well?

I like this mechanic analogy. If you fix the clutch, the car runs (feature complete) and the client is happy. If you don't fix the other something, the client will be back next week with an exasperated problem. Further, the client will be "unhappy". ...and possibly even accuse you of not putting the clutch in correctly because "the problem wasn't there before" or even accuse you of incompetence and move on to another mechanic.

...but If you start fixing the problems you see, you may end up fixing the whole car - which leaves the client without transportation.

So what should happen?

Well, comparing the software industry to the automotive industry has a lot of useful comparisons. I think that currently the software industry is focused almost exclusively on making, well, home made go-carts. Bad home made go-carts. I mean, taking-the-engine-out-of-the-lawn-mower bad.

We need to be focused on making BMW's. Componentized, quality cars. I am talking about component reuse. "Software factories" or whatever you want to call it.

...the problem is that the go-cart industry doesn't have the CAPABILITY to build BMWs. Furthermore, most people cannot tell the difference between go-cart software and BMW software. The program I wrote last week is a good example - the first program completed everything the client wanted! Transportation.

Why doesn't the go-cart industry doesn't have the capability to build BMWs? It comes down to a function of time, money, infrastructure, and investment. I see the primary variable as time. Deadlines. If it wasn't for the constant pressure of deadlines, I would be able to achieve so much more - and I am certain this statement is true for other developers as well.

I hate deadlines.

Permalink
Comments: Post a Comment