So starting the new jobs has given me the opportunity to take a fresh look at software and how it should be approached.
One of the questions that I have been pondering on alot is “What is code quality ?” Is it code that’s well documented ? Is it code that follows some sort of coding convention, code that is uniform throughout ? Well named variables ? Test cases ?
Obviously we all have our own perceptions, but in order to write good software I think its important to look at code from multiple perspectives, in order to do this I need your guys feedback!
Please tell me what you think makes good code ?
Something I have found very interesting in today’s “agile environments” is the adoption of processes.
I’m caught in an endless loop on my thoughts around the place of processes and how they should fit in a team.
Generally processes are put in place in order to protect the team, sort of like a safety net. Given this chain of thought people should be interested in following the process, and should try following processes as close as possible. At the end of the day, Its almost like wearing a safety belt.
This is where it gets tricky though, in many cases developers, testers or any other team members may not not see the need for this process, they may believe it is more of an impediment than anything else.
How should this be dealt with ?
Should the team be wholly responsible for the decision to keep or lose the process ?
Should the team be educated every time a process is put in place ? ( Its too often I have noticed that people simply follow processes mindlessly)
In true scrum nature it suggests that the team make these decisions. What if some of these processes have been put in place by parties outside of the team ? Furthermore these parties that may have a good understanding for the need of the processes ?
So I go back to my safety belt analogy, sure its a pain to put it on, but if you are unlucky enough to be involved in an accident I can assure you that you will wish you had been wearing it. Unfortunately in scenarios like this it seems its only when its to late when one may value the process ?
Another question I have is around how often should the necessity of a process be revisited ? Is agile not about constant improvement, about constantly looking at what went well and what could have been done better ?
Here is my take, but please add comments im really excited to hear other opinions on this…
I believe that processes should be revisited constantly, possibly with each scrum retrospective, its important to remember when doing this to consider the impact of failing to implemt and follow the process.
If the process is enforced by external party, and you feel that you dont see the need for it, discuss this with the party responsible and try to understand why it is they deem the process necessary, it may turn out that you have already covered the risk that this very process is trying to prevent. After all is this not what scrum is all about ? COMMUNICATION ?