Sean Walther’s Blog

Software Developers: Better and worse, a big difference

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: ant, build, debug, developer, software developer, steve mcconnell, web developer

Web Developers: How to work with small business

There are all types of web developers out there:

1. The Linux guy – no offense, these are frequently the most brilliant of all developers, having devoted much of their time to stuff that would blow the mind off of any other web developer (we know, javascript isn’t THAT hard compared to kernel development).  The problem with the linux guy (I know I’m stereotyping) is that they don’t have the business knowledge to help a client realize their actual goals.  These developers will take what they are asked, and execute it perfectly — just without analytical thought as to why the client asked for it.
2. The smooth business guy – He wants to talk.  To talk about all these dreams, but he can’t actually do any of it.
3. The reseller – He wants to sell the benefits of someone elses software package, telling you that it will solve all of your problems (without taking into account exactly what you need)
4. The ghost – you will see him once, but never again.  Occassionally you get an email from him asking for a check.  Otherwise sometimes things happen to your website as he chooses.  He seems weird, staring awkwardly at your employees.  
5. The “I took a web development course”/”I have a certificate” guy – having just gotten out of the local college’s web development course, he knows how to create tables, use javascript to access the DOM and change the style of a TD, and use PERL to handle a contact form, that would have been great 10 years earlier.  Not all “course” guys are like this, but there is a lot to web development.  I’ve sat in on some courses myself, and none have prepared anyone enough to handle real (modern)  web development.
6. The “designer” developer – a web designer that thinks they are web developers as well.  Coming with a fluency in HTML, you usually end up with large webpages with JPGs holding content.  Very SEO friendly.

It’s unfortunate that there’s really only one title for them.  They are all web developers.

As such many business are led down the wrong path when they sign up with a web developer, either in-house or otherwise.  

Working with smaller businesses has it’s own special challenges that most web developers don’t pay attention to.  Smaller business (I don’t want to say small, because these business are sometimes the largest in their communities) probably don’t have in house technical knowledge, experience on the web, or a full understanding of what the web can do for them.

How is knowing this important?  You shouldn’t take directions from someone who doesn’t know what they’re doing.  At the same time, that person knows exactly what they want, you just need to help them understand the best way to realize this.

One of the first questions I ask a client is, “How will this benefit you?”.  Client’s always want the coolest toys, as they think it’s what they need.  What they don’t always realize is: a blog needs content, poorly written content won’t sell itself, if they get more orders — they can’t support an increase in sales.

When a web developer talks to a smaller business, we should always help the client do the following:

1. Fully communicate what they want (sometimes a client has a great idea, but hasn’t thought it through)
2. Understand the best technologies to achieve their goals
3. Understand the impact on their business (more support calls, increased sales calls, cheap clients, international calls)
4. Know what other paths are open to them technically

Web developers need to be business consultants as well.  We need to help develop a mini business plan, set realistic goals, manage expectations, and extend our technical knowledge into the rest of the business.

I’ve had incidents where a customer wanted to “put up a blog”.  Of course, in the past few years, having blogs are the hottest marketing tools.  The client didn’t know that they need to write content to keep the blog up to date.  No one wanted to provide any content.  Secondarily, asked what the people were busy doing that would stop them from publishing content to a blog.  They were busy printing out mailings and posters for local community events.  Now we can talk about doing some print on demand.  That will help free up resources to make the blog.

The last point I want to make, is how do we know we did good work for a client?  Metrics are a great tool.  Either determine the number of sales calls per week before the project, or take a few weeks of web traffic reports to determine if you’ve had a positive spike in visitors.  How will your client tell their friends about how you helped them, if they don’t have real metrics?  

Help them understand, and extend your full capacities as a technical expert to your small business clients.

Tags: business consultant, consultant, Small Business, web developer