Software Development

Speed up development by slowing down

When Justin James realized his work was getting buggy, he took a step back and figured out why. Learn how his experience could help you from making the same mistake.

slow_down__thumb_092013.jpg
Every developer has at least a few bad habits. The longer I write code, the more open-minded and honest I am about my flaws. Most of these bad habits I uncover myself and hopefully go down the path of correcting. I believe this process is vital to getting better at anything you do, and software development is complex enough that there is always tons of room for improvement.

I had noticed (and so did others) that my work had started to get buggy. Sure, we all let a bug slip through our initial testing from time to time before it gets to QA, but I was letting some really obvious, easy-to-fix bugs through. It was not acceptable, and certainly not at the standard I hold myself to. It was time to reflect on exactly what was going on, why I was making these mistakes, and how to fix them.

I took an honest, comprehensive look at what was different, and I quickly narrowed in on the problem: I had started trying to do too many things at once. Long-time readers know that I periodically criticize the notion of multitasking because in truth, most people are not nearly as good at it as they think. I've always been convinced that trying to do two things at once makes each task take 50% longer with 50% worse results. And you know what? I proved it to myself.

When I saw what my mistake was, I put the brakes on it. Not only did the bug count go down, but the actual speed of development went up. The bulk of the time spent in the development cycle isn't the actual writing of the code -- that's just a bunch of typing and some mousing around -- it's in the back-and-forth: compiling, deploying to servers, testing, communicating with others, and so on. The more accurately the work can be done, the more you cut into the other things. In my current projects, it takes about 2 - 3 minutes to get code from my machine to a development environment ready for testing. Spending extra time but eliminating dozens of these cycles getting things right is a net gain. Even if it means that the time I spend goes up a little bit, it cuts out so much back-and-forth with the testers that it is a net gain.

As I have said in the past, trying to save time and cut corners by multitasking does not make sense, and when doing something like software development that requires a good amount of concentration, it makes things even worse. One of the best ways to speed up your development cycle is to stop trying to do so much at once, focus on one task at a time, and do it right the first time.

J.Ja

About

Justin James is the Lead Architect for Conigent.

15 comments
Shoaib.adil
Shoaib.adil

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

sparent
sparent

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.

RMSx32767
RMSx32767

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."

remspect
remspect

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.

tracy
tracy

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.

Spudbert
Spudbert

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.

jonathan_alvarez
jonathan_alvarez

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.

g01d4
g01d4

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

dogknees
dogknees

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.

Tony Hopkinson
Tony Hopkinson

I had a very productive day yesterday. I fixed several bugs in their code.... Five tasks marked as done, burn down chart burning down, Back for tea, medals and smileys on the dashboard. How do you have your productivity measured, if you say by how often you get it right first time, my next question is-: What's the weather like on your planet?

dogknees
dogknees

I don't think the boss is going to be happy about being closed or turned off.

Tony Hopkinson
Tony Hopkinson

There's never enough time to do it properly because all your time is used up doing it again. :(

agnelo.lubisse
agnelo.lubisse

I've worked for people that measured it in terms of % utilisation. If I remember correctly they figured out that 85% was about what they could expect from the typical developer on the team.

mikewor
mikewor

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.

sysop-dr
sysop-dr

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.