Fog Creek Software
Discussion Board




Working Slower = More Work Here is why:

I have noticed that if you let developers write code without regard to size, and execution speed then rate of development can really increase. In other words get it done and tweak it later. If the product becomes too slow and unwieldy then yes.......something must be done. Thus, the balance between how fast developers work and the size/bloat/efficiency must always be factored into the soup pot.

There is a lesson to be learned here.

There is a VERY FINE LINE between writing good software and bad software when developers are pushed too hard. In other words, that great developer team can be pushed hard and do amazing things. However, if the team is pushed beyond a certain level, then the quality of code written drops like a rock.

Since so much code is dependant on other routines, then those poorly written routines will cause the product as a whole to suffer. In other words, push the team too hard and the quality of the code they write suffers. Ok, now slow the team down and let them catch their breath,.......guess what? You still have that poor code in the product...and it will effect the overall quality of the product.

Now the team is writing quality code, but the product and rate of development will continue to suffer from the existing poor code base. Think of it like holding a long stick in your hands. A little movement at the wrist level causes a lot movement at the other end of the stick. The effect of poor or good code in a product is magnified much like the end of the stick as the project progresses. Small errors and omissions in the early stages can really bite towards the end of the project.

Good software design tends to be much smaller in size than poor software, and it actually runs faster. In other words really good code and design beats the pants off of poor code.

It follows that when you attempt to develop a product you must have the resources to do the job right. This is plain and simple. Thus, to complete a project you can drop features or perhaps allowing more time to complete some code. Much of scheduling and management of a software project is to manage and *restrict* resources.  Fine, ok,  you can restrict features, but those existing features that you keep must be well written and designed. Do not confuse the issue of cutting features with the idea of speeding up the writing of code. Don’t try to speed up the writing of code. Even more important is not to speed up the design process.

Last year I had a software project get into trouble. Deadlines etc. were slipping faster than a slippery slope. The company had a “season” and we missed the deadline for implementation of our software. Worse was that this software was mission critical and we had convinced them move over to this software *while* we continued to implement critical features. The business could not function without this application (it was a booking application for a ski tour company). We reached a point where it was clear that we could not meet the deadline.

Fortunately they still had the old computer system (sort of!). That system was now 10 years old (including the hardware!). The old system was a text based 8 user rs232 system. It was in pieces and this years data was now in the new system. The new system was a Windows based product. The old system was written when the Internet and things like email did not even exist. The new product was totally integrated with ms-office and had a lot email capability. At any rate, we had to move back to the old system. It took about 1 week to get the old system running again. That whole week, and what was accomplished is a great story.. ...but I’ll save that for another day. The staff simply re-keyed in all the bookings that had been done on the new system back into the old system.

Normally, I am the one who is brought in to fix a computer mess....not create one! I never had a project fail like this. What the heck happened?

I took 3 weeks off in the Month of December (last year) to rest up, and try and figure out why this project got into such trouble. The above explanation about speed of code development was my conclusion. Since deadlines were fast approaching, the quality of code design began to slip as I attempted to write more code at a faster rate. In fact I was writing more code, but it was not nearly re-usable and well designed. Since the code was of poorer quality then my estimates as to how long certain tasks would take were also incorrect (and they in turn affected more modules of code). Only when I reduced the rate at which I developed code did in fact the rate at which the project move forward *increase*.

Slow down and you work faster! Neat huh?

A good implementation of a design allows one to “zone” in. Poor code prevents developers from “finding the zone”. I was wondering why I was having such a hard time “finding the zone” when writing code. Some tasks that should have taken a day were taking 3, or even 4 days. When a developer can’t find the zone, then productivity drops down to a snails pace. Poor code and poor implementation of a design means that the developer(s) cannot get into the zone.

There have been quite a few books that have mentioned that removing deadlines seems to *increase* the rate at which developers write code. In the real world we can’t just develop with no deadlines. However the conclusion that is actually being made here was not really to remove deadlines...but to simply slow down the process until a very high level of work is being done. So, the real answer here is not to remove deadlines...but to keep the quality of code being written at a very high level. This is also probably why Extreme Programming (or two programmers sharing the same work station) probably works so well. Each person is actually doing less work...and has more time for better design/implementation.

It also hints as to why so much of the open source software is of such increadabbliy high quality. A very large portion of open source software is written at the CORRECT speed, and thus tends to be of a very high quality.

Tuning and playing with the rate at which development occurs is not to be overlooked in any software project.

Slowing down the rate of development gives the mind more time to “think design”. Have you even been stuck on a design for a few days? You will notice that those several days seem very frustrating and very unproductive. However once your mind “SEES” the design that is going to work...then you able to produce code like a hungry snow blower working on a snow bank in January.

Just how do most software developers work?

That idea of “seeing” the design or having a mental picture of the design is required before one can really zone in. Without this mental conceptual view then no real high rate of development will occur. In fact, for some no development will occur until the mind “sees” the picture. My point here is that when you slow down the rate of development, then the mind has more time to get that “view”. Once the mind has that view then writing code is like finally starting up the snow blower (or, for you southern people...the lawn mower).

I also want to stress that this slowing down is not to remove any and all pressures. We are not talking about sitting around and drinking coffee all day. The amount that you slow things down can be very small, and result in large gains in developer productivity. However, sometimes you must slow down so much that must stop all together.

By the way, I did finish the critical parts of the code and the company started using the system for this season. It has had amazingly few bugs and none critical so far. The company is so happy with the new system that they threw me a nice free ski trip to the Mountains.

Albert D. Kallal
Tuesday, January 08, 2002

I agree that design take times. It can be speedied up, but not much. The same goes for coding; if too much code is put into the application in a very short amount of time, it lacks the time to sink in. It won't be re-used or refactored. Just some stand-alone code. Also communicating consequences of implementations does not go well, ending up with Product Managers who don't understand their product.

Sometimes it looks like it that it doesn't matter how hard i try/work; the results are mostly the same.

There is some maximum speed at which you can develop, exceeding this limit decreases the quality (enormously) and increases development time further down the lane.

Does anybody know if there is some literature about this subject?

Stephan Westen
Tuesday, January 08, 2002

Steve McConnell's "Rapid Development" has a whole chapter
called "Overly Optimistic Scheduling".
Some citation from this chapter:
<<
Fred Brooks pointed out that "more software projects have gone awry for a lack of calendar time than all other causes combined" (Brooks 1975). A decade later, Scott Costello observed that "deadline pressure is the single greatest enemy of software engineering" (Costello 1984).
>>

Andreas Wicker
Tuesday, January 08, 2002

To expand on the point about XP... (I'm not obsessed, honest. It's just the methodology I've been using lately so it's fresh in my mind)

Extreme Programming's take on this is that a project has four variables: Scope, Time, Resources and Quality.

You are encouraged to think of a big machine that code comes out of, with four levers on the side. You adjust these levers to make the machine run efficiently.

The first rule is that the Quality lever should always be kept up at 100%. If you reduce this, you will get a temporary burst in speed, then the project will slow down as the short-cuts taken come back to haunt the programmers.

In practice, you tend drop the Quality lever down a bit just before deadlines, you just have to remember you'll take even more time than you saved to catch up after the deadline has passed.

Adjusting the Resources lever has unpredictable effects, as per Brooks Law. The effect is commonly the opposite of decreasing quality - you'll get a temporary slow-down as the team assimilates the new members, but an eventual increase in speed as the new team starts working.

Many projects, however, would have a theoretical maximum resources (dependant on project size and complexity), after which adding more will only cause confusion and slow things down.

So really, the only levers you can control to have a reliable medium term effect are Time and Scope. If you find your project is going to be late, the only way to fix this is to either increase the available time (push back deadlines), or decrease the required scope (remove features).

Charles Miller
Tuesday, January 08, 2002

QUOTATION:

To suffer the penalty of too much haste, which is too little speed.

ATTRIBUTION:

Plato (c. 427–347 B.C.), Greek philosopher. Statesman

Ged Byrne
Wednesday, January 09, 2002

*  Recent Topics

*  Fog Creek Home