We have often wondered and have been asked this a number of times, could it be:
- The three great virtues of a programmer: laziness, impatience, and hubris - Lary Wall, Tom Christiansen, Jon Orwat, (2000) Programming Perl
, O'Reilly Media Inc.
Which the Oxford dictionary gives the above words meaning as:
- Laziness, a derivative of lazy a. & v 1. a. unwilling to work; appropriate to or inducing indolence; (of river etc) slow moving.
- Impatience, a derivative of impatient (-shent) a. not enduring with composure (at, with); (of action) indicating such feeling; intolerant of; restless desirous (for anything, to do); hence or cog.
- Hubris n. insolent pride or presumption; (Gk Tragedy) overweening pride towards the gods, leading to nemesis; so ~i'stic a. [Gk]
The book gives the words meaning as:
- laziness The quality that makes you go to great effort to reduce overall energy expenditure. It makes you write labor-saving programs that other people will find useful, and document what you wrote so you don't have to answer so many questions about it. Hence, the first great virtue of a programmer. Also hence, this book. See also impatience and hubris.
- impatience The anger you feel when the computer is being lazy. This makes you write programs that don't just react to your needs, but actually anticipate them. Or at least that pretend to. Hence, the second great virtue of a programmer. See also laziness and hubris.
- hubris Excessive pride, the sort of thing Zeus zaps you for. Also the quality that makes you write (and maintain) programs that other people won't want to say bad things about. Hence, the third great virtue of a programmer. See also laziness and impatience.
For me the high lights are the following:
- Continuous Testing.
- Design and implementing software over just implementing software.
- Being flexible towards the business needs or requirements.
This is the idea of having small unit tests associated with each module of code that proves the behavior of the code. This can be use to ensure all changes have not adverse effect and also Test Driven Development changes the way developers approach a problem as they have to think a little about what they are going to do and create a skeleton of a test and not worry about the detail until they come to develop that behavior.
Once a project as a number of code modules and associated tests this can be controlled by a build system and help the automation of the project allowing anyone to get a release from the Source Version Control System, verify the code passes the test and deploy to the appropriate environment.
Design and implementing software over just implementing software
This is one we really believe in but for some reason is the hardest to convince people to adhere to has people believe that is takes to much time or cost to much money. When I say design I mean fully documented so as the team scales or changes everyone can read the design specification and get fully up to speed.
This does vary depending on the industry that the software is being developed for but I would hope that the software engineering industry would pride itself in doing design before implementing the code. There are lots of tools that can help in doing software design, our favorite is Enterprise Architect by Sparx Systems.
Being flexible towards the business needs or requirements
This is the main reason we insist our development teams we work with to design their software and unit test the software. This allows us and the companies we work with to say yes to our clients when they change their minds or a deal relies on the System working in a particular way.
That only gets you half way to achieving this goal. You also need a software architecture design that the developers are will to follow and a good process to identify the impact of the change to know how much it going to cost.
If the cost is to much it can always be put into the softwares roadmap so your clients know you have listened. The main reason I like to develop flexible and configurable software is to be able to say yes to our clients.
By doing TDD you can forget about a good design, at least in the beginning. It makes you implement just the basic functionality you need to pass the tests, nothing more, nothing less.
ReplyDeleteAlso documenting design in Agile environment will cause more problems than bring some value. You might have an overall spec, but the design probably changes too often for anyone care to update the design docs.
Interesting point Petr and I agree that the evolution of the code changes the design of the system very quickly in an agile environment but that does not stop you documenting the code via javadoc comments, producing API documents that need to be clear and the clear they are the better your code will be, and also using reverse engineering tools to do analysis of your code either as part of the continuous integration or as part of the reflection of progress or diagnosing a defect.
ReplyDeleteIn TDD the test is your spec/API. I generally write javadoc only when really necessary (ie a difficult business requirement), otherwise the code should be self-describing. From my experience that works better as even Javadocs are usually left unchanged and soon obsolete.
ReplyDeleteThat is great for a developer work on the project but how do you communicate back to business analysis, product owners and project managers or other developers using your API with access to your code?
ReplyDeleteIts great when the organization has bought into something like cucumber (http://cukes.info/) then I can see how that can work well.
I guess during daily standups and possibly demos ;-) Product owners & TA's write the cards, so they define the requirements.
ReplyDeleteFor 3rd party devs you obviously need API docs, but that should hardly change so documenting that makes sense.
I read a very beautiful and very important article that I enjoyed reading. You have shared a lot of information in this article. Managed IT Support Service in Melbourne
ReplyDeleteGreat postt thank you
ReplyDelete