Browsed by
Author: imel

There is no such thing as a quickly adding a new software feature

There is no such thing as a quickly adding a new software feature

How often have you though that you could quickly add a new feature to your system? If you ask me, the answer is many times.

How often did it turn out to be quick? For me, none so far.

Adding a new feature quickly implies the following assumptions:

  • You know exactly what you want the actual requirement is
  • You know exactly what needs to be done
  • You know exactly how this will impact the rest of the system

Most of the time at least one of these assumptions are wrong, more than often two or even three. This means a job that you thought would take a day turns into a week or even two.

Another seriously delaying factor is the dreaded scope creep. Often business wants more once they see what you have done. This can be managed, but what is far harder to control is the internal force that drives the top developers. We always want to over deliver, which means we keep adding more and more as we code, causing our own scope creep.

My rules to manage this is simple:

  • Rule 1. Write down exactly what you want to accomplish
  • Rule 2. Write down exactly how you are going to accomplish it
  • Rule 3. Stick to the two rules above, no matter what

If you decide halfway along that it would be a good idea to add X, Y or Z features, don’t. Resist all temptation. Refer to the rules above if confused. Only once your new feature is done can you consider doing more, but now you can step back and consider the bigger picture before you dive back into the code.

Own the bug

Own the bug

Bugs slipping into code is inevitable, no matter how carefully we code and test. I have created many bugs in my day, and still make the odd mistake to this day. It is how you respond to your bugs that matter.

If you know there is a bug in your code, own up & fix it. If there is a chance that it has gotten out to live sites then patch & release a fix. If something on the customer side got affected by the bug then make the customer aware and sort it out. Not disclosing creates an atmosphere of mistrust, as the customer is bound to find out eventually.

If you work as part of a team, there is no debate here. Make sure your team knows what is going on. They cannot have your back if they are in the dark.

Read More Read More

Rise of the specialist coder

Rise of the specialist coder

When I started my career in software development over two decades ago there was no such thing as a specialist  coder.

Programmers as we were called in those days were required to do a mix of jobs. Gather business requirements, design the solution, code it and get it implemented. This included the graphic design, the end user training, etc. This attitude of “do it all” has served me well in my career. I have seldom been unable to solve any technical obstacle myself.

Today it is very different. Most developers specialize in front-end, back-end (server side) or ux (suer experience). Graphic design has diversified just as much.

Read More Read More