Discussion on:

Speed up development by slowing down

The other great lie we tell ourselves is how long we can work productively in a day.

My boss of many years knows he can get a solid 6 hours of productive programming work from me in a day. Any more, and the quality starts to drop and with it my productivity. It's pointless doing an hour of "work" that takes another 45 minutes to fix the next day.

While I'm sure there are people that can do 10 hours of solid development work, I don't think there's that many of them, and I know I'm not one.

I had a 'walk on water' programmer working for me, he would put in long hours but his code was buggy. After discussions, he agreed to checkpoint his code at 2pm every day. We then sat down and proved his afternoon/evening coding had far higher bug rate and introduced bugs into what he had coded that morning. So together we "banned" him from coding after 3pm and he spent the rest of the afternoondoing documentation.

but for me it's the other way around, I can't wrote good code before 10 and most of my really productive coding time is from 1 to 4:30. Morning person vs afternoon I suspect. Each of us has a time when we are at peak performance and if we can determine that and work things like meetings and distractions to outside of that period we can maximize how much we get done a day.

Or shouldn't I ask? Perhaps a little thinking before "a bunch of typing and some mousing around" might also help.

I do agree with the issue of multitasking when programming, it's never good. If inevitably you need to work in several project at the same time (always happens), the best thing is to do multiplex, ( like the old multiplexers on network) just dedicate a fix time to each project, lets said half a day in one project, half a day in another. but never overlap the time or the false multitasking will hit you.
Ahhh and planing a lot at the begging always help.
Note: Programming is a brain multitask by it self, you need to thing about the good code, standard, the DB , the relations , methods, objects, internal rules,and heap of things to bring to the code to make it work fine. don't bother yourself trying to do multi-multi tasking, just don't work.

I have started to slavishly adhere to the principles of Test-Driven Development (TDD). Now I write about twice as much code the first time around, but it always passes QA the first time. It actually speeds up QA, because that team can analyze my End-to-End tests, which I write first, finding defects in the specifications before they start their testing.

Overall, I would guess this triples to quintuples our speed of development.

My development teams work 4 10 hour days for many of the reasons mentioned. The QA teams also work 4 10 hour days but the day off is not the same as the dev teams. I have found that more than 10 hours is counterproductive and often people leave at 8 hours instead of finishing that last bit they have in their head.

In any event our productivity is way up and the developers are always eager on Mondays after having Fridays off. It also helps with keeping people around for a longer employment period and reducing retraining costs.

I agree multitasking is not a good idea when developing. But sometimes it may not be up to the developers. When I am multitasking, my train of thought hops onto other tasks from time to time when I realize the related aspect of those tasks need to be fixed/enhanced to keep up with what I am doing. I need to make sure I document those thoughts right away before I forget them so I can follow up later on.

There is always time to do it correctly; there is not always time to return to the "loaded with undocumented features application" and correct the problems. Remember what John Fogarty said "Someday never comes."

While I don't disagree that we don't multi-task - we only task-switch - I think the root of the problem is with the interruption.

Back in my coding days, I tracked the number of interruptions while I was doing code development. I definitely saw the direct relationship between that number and the number of defects injected in my code.

The lesson learned? Close and turn off things that can disturb you - phone, email, door, ...

You will stay in the zone longer, making you more productive and efficacious.

Developers are made for work no matter you are productive or not you have to work ,if you are productive it will help you a lot otherwise your only work will be fixing bugs in your own code