Practising Best Practises in Your Software Development Process - Bridging the Knowing-Doing Gap in Software Development
(Page 6 of 7 )
Having explained the causes of the ‘Knowing-Doing Gap’, let us now consider some situations when it might arise during software development, and how the effects can be mitigated.
We all know that devising a project plan is not the same as executing it; knowing how to solve a programming problem is not the same as solving it; and reading about a new technology or algorithm is not the same as using or implementing it. These are all necessary pre-cursors to action, but are no substitute for the actions themselves. If the action is important, then make it a formal part of your software development process and, as part of that process, ensure that it actually happens.
Software development is not like a factory assembly line, in which every component is, and should be, just the same as the previous one. As developers, we strive to achieve a certain level of repeatability, since this makes the process much more predictable, but slightly different problems and problem contexts often demand different solutions. You should, therefore, identify and challenge your assumptions early in the software life-cycle, so that the implications of lazy thinking can be addressed before it becomes too late. You should also encourage peer reviews of code as a part of your process, so that ground-level assumptions and practices do not go unchallenged. At a strategic level, changes in the market-place can also make it dangerous to use memory as a substitute for thinking. Organisations need to be agile and react to changes in the market-place to maintain their market share.
How often have you been scared to change code because you are afraid of the consequences? You need to make a change, but maybe you don’t completely understand the code and the guy that wrote it has left the organisation. Your fear is preventing you from achieving the best result. To avoid such a situation, encourage joint ownership of designs and code in your team, so that many developers can maintain the code base. And when it comes to the crunch, be brave -- but make a back-up!
It is common knowledge that what gets measured gets done, and what is not measured gets ignored. Therefore in the very act of measuring anything at all, there are obligations to your organisation. You must make sure that what you are measuring reflects and contributes to the goals of your organisation, as well as reflecting the importance of both long-term and short-term goals. So, for example, measuring the number of lines of code written by developers is a bad measure of productivity, bearing little relation to project progress and no relation to the fitness-for-purpose of the end-product. Also, what does it mean to say that a task is 90% complete, when the last 10% always seems to take as long as the first 90%?
Next: Conclusion >>
More Development Cycles Articles
More By Simon White
/ 38 
