build

Software Developers: Better and worse, a big difference

Friday, October 16th, 2009 | Business | No Comments

In my days as a web developer I’ve probably worked with about 100 other developers.  Every team I’ve been on, I always knew who would (correctly) pump out bug after bug, and who would sit with a single bug for weeks.

Think of the slowest developer you know.  They usually are reluctant to learn new development methods, new software, and practices.  These slow developers can spend days or weeks on a single bug, constantly absorbing your time as they stare blankly at a bug.

Sometimes there are reasons for this:

  1. They have never worked in this environment
  2. They do not want to ask for help
  3. The bug is actually hard
  4. They can’t even find where to begin looking

Just today I found a blog written in July by Steve McConnell titled:

10x Software Development

Numerous studies have found 10:1 differences in productivity and quality among individuals and even among teams. This blog contains Steve McConnell’s thoughts about how to move toward the “10” side of that 10:1 ratio.

How true is that statement?  We’ve all been on the projects where we wish we had “5 Toms” or 3 of another developer.  Why?  Not only does he get it, he knows how to handle software development.

How can you improve your software development speed?

First of all, speed isn’t everything.  Lets define speed, by the total time it takes you and all others involved to complete (not just submit a fix) a task.

If you get a task and submit it for approval (or even worse, just deploy it) consider the time it takes the QA team to look at the bug, boggle their head when it still isn’t working, document the bug and assign it back to either the project manager or yourself.  Yes, the QA team would have looked at the bug anyway, but now they have to do it again.  The project manager now has to review this bug, and reassign it to you, or you yourself have to read it again and develop again.

There is a huge delay in speed when submitting a completed task that is not complete.

To establish a baseline, it is top priority to submit fully tested and fixed bugs.  Otherwise you are just wasting everyone’s time.  The bug won’t go away, you know it will come back.

We are now submitting actually fixed bugs (we tested ourselves, and they work in all possible scenarios) … how can you improve your speed?

  1. Talk to other developers on the project, someone always has a better software package, or better way to handle those time consuming repetitive tasks
  2. If at all possible, automate compilation.  Use Ant or a build script, but somehow, you need a way to quickly (and CONSISTENTLY) compile your work.  Nothing sucks more than trying to troubleshoot a bug, only to realize you didn’t compile the same files the same way.
  3. Expedite testing of your tasks.  Local servers are great for this (and make it easier for the rest of the team).  Every time you test a change, you have to spend time doing the actual test.  This takes maybe 15 seconds, but sometimes you do this 100s of times for every bug you complete (or more).  15 seconds * 100 times = 1500 seconds that is 25 min. of time.  If you get it to 3 seconds, you have just gained 20 minutes worth of time to fix that bug.
  4. Always search for new tools.  Aside from talking to other developers, you can research better ways to do what you are doing.
  5. Communicate with everyone.  A project takes a team to complete (usually), so if you are speeding ahead and done weeks ahead of everyone, the project is not going to be done earlier.  If you are ahead, help out your team members, proactively provide faster / better ways to do tasks.  Additionally, it is easier for the client to react to a delayed delivery when notified of it earlier on. While it may take time from your schedule to say you messed up estimation (it happens, a lot), the client won’t have to scramble and can establish a well thought out backup plan.
  6. Keyboard Shortcuts.  When I code I get into a groove where I hit buttons almost like playing music.  There is a beat to saving, tabbing over, repeating last compile command, tabbing over again, and refreshing a web page.  How many times do you save a file?  Ctrl+S is much faster than using your mouse (I know, it’s a basic example, but you get the idea).
  7. Don’t get stuck. Obvious, but still not easy to do.  When you get to a bug that you just can’t solve.  Don’t.   Move on to another one that you can, notify the team that you are stuck on the bug, maybe someone else can fix it who has a different perspective on the issue.  Software development shouldn’t be about ego, it is about working with everyone towards a single common goal.
  8. Make a list.  I hate lists.  Ask anyone who knows me, family, friends.  They are great for putting things in perspective.  If you have a list of 20 tasks to do this week and are stuck on #3.  You know you should MOVE ON.  Getting 3 out of 20 is much worse than 16 or 17 out of 20.  You also start to see groups of tasks that involve the same set of files or code and can work on them together.
  9. Test frequently.  Sweeping changes to code never work.  I’ve been on countless projects, and then minute I start feeling bold and implement 2 or 3 fixes, I always have to go back and fix something.
  10. Learn to debug code.  I cannot emphasize the importance of this one enough.  Debugging code is perhaps the single greatest skill any developer can have.  Usually the hardest part of fixing a bug, is finding the bug.  Here are some hints:
    • Binary search is amazing not just for searching, but sub dividing code.  Comment out half of your program, see if the bug is in that half or not.  Even if you have no idea where the bug is, you can eliminate 50% of your options with a few comments (ok, sometimes you can’t quite do this, but you can get close).  Within a few attempts you will narrow down your scope.
    • Don’t be afraid to get ugly.  I always make sure when I’m debugging, to make things as visible as possible.  If I’m debugging a flash project, I make big ugly bright colored shapes appear when code is executing.  Use system.out, writeln (Pascal, there’s an old one), trace, alert, anything that will help you know more bout what you are doing
    • Use debuggers.  Debuggers are your friend.  You can see variables, set breakpoints to inspect loops.  Frequently developers think they can just “alert(‘test’)” their way out, but there are many free debuggers out there (some are already on your computer).

Another big one, is don’t post blogs while working!  Focus.

Usually some non code related things get me going faster too.  A clean workspace, work friendly music (sometimes classical, sometimes club music, you pick your mood).  Sometimes its a snack you grab in between bugs as a treat.

Best of luck everyone, check out that blog again: 10x Software Development

Tags: , , , , , ,


Please share, it makes me happy:

Subscribe to Email Alerts

Follow Me

Follow seangw on twitter

Archives

Categories

prestashop theme

virtuemart template