The Ten Toughest Tasks in Development

The toughest tasks in development have little to do with writing software. Coding is an exercise in logical thought; it’s straight-forward compared to the other activities developers undertake on a daily basis. If you consider yourself a half-decent amateur programmer, ensure you can overcome these hurdles before leaping into the professional realm…

1. Explaining what you do

Explaining the software development process is difficult. Non-coders may know a lot but, by definition, they cannot code. To them, we spend our lives hunched over a keyboard in a darkened room drinking coffee.

You will encounter the opinion from friends, family and colleagues that coding is “not a proper job”.

2. Visualizing software solutions

Given a set of brief — and often poorly-conceived — requirements, you’ll need to devise data repositories, code architecture, algorithms, communication protocols and any other technical facets which encompass a solution to the business problem. Then you need to explain it in layman’s terms and deliver within a specific time-frame.

Few developers can do it well.

3. Estimating delivery times

The bane of every developer’s life. It’s impossible to determine the time required to complete a task when that task has never been done before. Similar code may have been written, but it’s not in the same system with the same issues or restrictions.

Experience helps, but most coders under-estimate. That’s partly because they only consider the coding side and forget to the other activities on this list.

4. Working on someone else’s code

There are an infinite number of ways to create a software solution. Working on someone else’s code means spending many hours wading through thousands of lines of code to understand what they were thinking. Of course, this is made more difficult when the original developer didn’t believe in comments or documentation — then abandoned their half-finished project.

5. Scope creep and bizarre functionality

While agile development makes an allowance for scope creep, it doesn’t make it any less frustrating — especially when you’re asked for dumb functionality on a whim. You know it will fail. Your team knows it will fail. But the client knows better and, when failure inevitably occurs, it’s your fault because you didn’t believe in their vision.

6. Achieving a balance between under and over-optimization

Complex software is never be perfect; there’s always a better approach. It’s possible to optimize indefinitely and that’s why software projects are never delivered sooner than the due date.

On the flip side, there’s the “that’ll do — I’ll improve it later” mentality. The code will work today but you know it’ll cause anguish and failure tomorrow. Of course, you’ll never fix it; it’ll be left to the next poor developer.

7. Testing your code

You may write unit tests and pass software to teams of testers but bugs still materialize…

• Software is complex and may contain thousands of lines of code. There may be billions of possible interactions and pathway though the system; it’s impossible to test them all.
• Similarly, software interacts with different software on different systems under different conditions. You cannot test every eventuality.
• Writing good unit tests is tedious and hard work. Ideally, tests should be written before development commences — but try explaining to your client why four weeks of effort has resulted in no usable software.
• Unit tests won’t highlight every flaw. In a perfect world, a separate team would write the tests and actively compete to discover problems. Unfortunately, that’s too costly and time-consuming for most projects so the development team writes the tests. They will sub-consciously avoid any strange edge cases.
• Programmers have a logical approach to everything. Users rarely do; they will find issues you never expected.

8. Documenting your code

Documenting your code is laborious and time-consuming. Few developers are good at it and even fewer will take the time to read it.

9. Dealing with IT problems

You’re working with technology every day. You may be an HTML or PHP developer but you’ve probably had to overcome issues such as hard disk crashes, driver conflicts and software failures. It’s not your primary role but, unless you solved the problem, you wouldn’t be able to continue your development tasks.

Unfortunately, to everyone not involved in IT, you know everything. When they have a problem, they’ll contact you rather than spend any time trying to work it out for themselves. It doesn’t matter what the issue is: you use computers so you must know how to import payroll data into Sage, configure Oracle, or discover why outgoing email is failing on their Blackberry.

Of course, these interruptions won’t have an impact on the delivery schedule or be chargeable, will they?…

10. Dealing with people

The tasks above can be summarized as “dealing with people”. Few non-experts would advise a pilot how to fly a plane or suggest house re-wiring techniques to an electrician, but they’re happy making bold suggestions about software development.

I’m afraid there’s no way around it; you just need to accept that half the world has below-average intelligence!