I tend to wake up early morning and spend some time reading on my phone. Today was not different. I browse my Tweeter account about three times a day. Typically I do not reply or re tweet. I am a firm believer that software engineering and understanding the inner works of computers and how operating systems run applications is extremely important in producing quality software.
The following is a tweet from David Mwathi (re tweeted by Marcus Biel):
“Good programmers are good because they make a diagram before they start coding”
It holds a key point in software development. With the advent of Extreme Programming and Agile it seems that documentation has been chastise by most programmers. I have read many articles and books that construe documentation as a useless artifact in software development because end users do not run documentation, they run the application.
I completely agree with the above observation that users do not like or want to read documentation, especially when it describes the software. So why should a development team (regardless of size) spend time documenting? The answer is quite simple yet seems to evade most programmers and managers. One cannot embark on a trip without a plan / map. One needs to know what is needed (the destination) and what route (including alternates) to take (how to get from the start to the end point) to reach the destination within time and money constraints.
For decades I have put together sensible documentation (not Victorian novels) for the system and tasks in software that I have developed. Started with MacDraw and MacWrite (that should give you an idea regarding how long I have been documenting before coding) and today I am using Visio and MS Word. I have used UML tools, but for cost, simplicity and acceptance, decided to make the necessary versions of UML diagrams using readily available tools.
Of course, drawing a diagram does not guarantee that the software under development will be a quality product. Sensible documentation needs to be reviewed and updated as needed with insights obtained during the development phase.
I have lived several situations when something (typically changes) is urgently needed and management and peers want to start coding the solution without prior documentation (i.e., no thinking process). In general the results lack quality and tend to be plagued by issues. Stop, think (diagram and small description should do) and act seems the proper way to achieve the goals in the shortest possible amount of time and using less resources.
If you have comments or questions please let me know.
John
John.canessa@gmail.com