Never commit to anything without doing proper research first
On a couple of occasions I have been approached by one of my clients wanting a change to a system I or one of my colleagues wrote. They will start off by saying that they need a ‘small’ addition and that it is really simple. (That usually coming from somebody with NO programming experience at all) They will then proceed to explain the change and at the same time tell you that it shouldn’t take you more than x amount of hours to complete.
This is probably one of the most frustrating situations for me. I really dislike it when non-programmers tell me how to do my job. What makes it even more frustrating is when such behavior comes from a really likable person. You are almost tempted to agree with them. But don’t deviate from your game plan. This game plan is called research. So, you need to do the following (there are different procedures here, but I’ll list the basics)
- Always define the addition or modification properly.
- Clearly define the affected systems.
- Identify possible risks.
- Ensure that you clearly understand what change needs to be done.
- Document this change or addition in a change document. (The client must sign this)
These basic steps will at the very least ensure that everybody is on the same page. And most importantly, that you make the change correctly, on time and within budget. And lastly, the golden rule to never forget is this… If you understand it, you can code it!
