Clearing out some clutter from my document repository, I discovered a half-baked and half-completed document from a few years back, written in an attempt to articulate what I felt at the time were essential steps to improving the developer culture within a particular customer’s organisation.
This is stuff that has been written about a thousand times, and much of it is now part of mainstream developer culture (well, almost). Some of the points will even seem a little dated. But like trawling through long forgotten photographs, it can be interesting to see were you’ve come from.
I should point out that this was written in 2004/2005, not long after reading Mary Poppendieck’s Lean Software Development - thus the frequent references. It was also written with reference to a particular customer’s setup. Not every organisation is the same, so some might disagree with these points or perhaps find that I didn’t go far enough (it was half-completed afterall), but I do think most of the points hold true today regardless.
1. Foster a culture of technical excellence:
* Make training a priority. Allocate a training budget, and make sure it is spent. Work closely with developers, their mentors and tech leads to ensure that training needs are met. At the same time ensure that training is appropriate to the needs of the individual and the company (i.e. spend the budget wisely).
*Encourage staff to purchase technical books and literature (and make it easy to do so). A book purchasing scheme is not only an excellent and affordable way to train staff, it is also highly motivating: Staff consider it as a perk. Developers should be free to buy books on all aspects of software engineering; requirements elicitation, testing, process, design, etc. Create a recommended reading list on the company WIKI.
*Encourage and reward certification. Be prepared to fund certification training, time-off and the actual exam(s).
*Conferences. Every developer should go to at least one, and come back inspired
2. Ensure all developers are grounded in key software engineering skills
* Educate staff on requirements elicitation techniques: breadth before depth, use casing, user stories, prototypes, etc.
* Educate staff on testing and testing techniques: Boundary testing, equivalence classes, unit testing, acceptance testing, etc.
* Ensure developers are grounded in OO design principals and methods: Open-Closed principle, DRY, design by contract, test-driven development, refactoring, single responsibility principle, simplicity, etc.
3. Make quality a cornerstone of all activities
* Introduce code reviews: Define a simple, effective code review process. Reviewing is not just about catching defects early (although this is their primary purpose), it’s about shared learning and applied consistency.
* Introduce (automated) developer testing. Make developers accountable (see empowerment). The culture of ‘I think it works, so I’ll throw it over the wall and see what happens’ should be replaced with ‘I know it works because I’ve tested it and have the automated tests to prove it’.
- Ensure that developers understand the difference between unit testing (building the code right) and acceptance testing (building the right code).
- Ensure developers understand the significance of TDD as a design methodology. For product development to be truly cost effective, the concept of sufficient design should be understood and adopted by all.
* Introduce continuous integration (CI): CI tools such as CruiseControl will, when used as an integral part of the development process, reduce development cost. Defects are fixed when introduced, not when found 3 months later during manual testing. CI is an essential ingredient for any software project.
* Introduce ‘nag-ware’: Use freely available tools to inform developers when standards have been broken, OO coupling is bound too tightly, etc.
4. Define and implement programming guidelines
* Define exception handling guidelines: Developers should understand the difference between checked and unchecked exceptions. They should also, by and large, avoid the use of checked exceptions– they complicate code and the overall programming model, particularly with large scale applications. (Note that Java is the only language to use checked exceptions.)
* Define logging guidelines: Moreover, don’t write entry and exit diagnostics: Use AspectJ to weave standard entry and exit logging rules into source code. Not only is code clean and quicker to write, but logging is more consistent since one aspect/approach exists for the entire application. (Logging is a cross-cutting concern, i.e. something that applies to most packages, classes and methods and as such be removed from all modules.)
* Define Javadoc guidelines: Javadoc, and to a lesser extent unit tests, should be used to document intent. Developers should understand how to document using Javadoc. Documenting at the package, class and method level encourages developers to reason about their code. Javadoc should be published via standard tools, e.g. Maven.
* Re-define style guidelines: Remove superfluous commentary requirements from source – it is simply noise, is time-consuming to maintain, is difficult to read and is mostly unnecessary. Also, more generally, define when and how to comment code. Insist that source code contains no hard tabs (so that it can be viewed in multiple editors). Insist on explicit imports. Go with convention - use either Sun’s or Eclipse’s formatting rules.
* Allow guidelines to be adaptive: Guidelines are not written in stone and should change with the times. Guidelines that are found not to work should be simply removed altogether.
5. Create Slack for All Development Staff
* All Developers, but especially technical design authorities, should be given the time and space to learn. The implication being that time invested now will be time saved in the future. Slack is about being given time to look above the parapet, to investigate new technologies, tools, techniques and methods with the goal of improving productivity, quality and lower costs.
* Free technical leads to mentor and guide the team. Don’t assume that every team member understands your vision – people will go off in their own direction if not otherwise instructed. Some will go off even when instructed. Most developers, particularly graduates, need to undergo an apprenticeship – mentors and technical leads should be free to facilitate this. (See nag-ware.)
6. Avoid doing things that can be done with tools
* Use AOP to weave in logging, security, etc. Never write that which can be automated. Never repeat cross-cutting concerns at the beginning and end of each and every method, e.g. entry and exit diagnostics, security, transaction demarcation, policies, etc. Use Spring.
* Use Maven to publish test results, javadoc, Checkstyle/PMD reports, change logs, Subversion source cross-references, etc. Maven provides excellent visibility into the current state, and therefore health, of a system.
7. Empower developers (but make them accountable)
* See Mary Poppendieck’s Lean Software Development.
* Adopt test driven development (TDD) as a standard development/design methodology. Developer tests improve confidence, trust and quality. Tests drive design. Tests provide visibility into a systems health. Tests tell you how far you need to bring a design (is it sufficient?). Developer testing should be placed firmly at the centre of every developer’s working practices. (If you can’t test it, then you can’t code it.)
8. Communicate regularly but informally (whenever possible)
* Use a WIKI. Encourage developers to use the WIKI on a regular basis. The WIKI should be viewed as the main portal for all informal but informative information. It should be used to publish standards, processes, and titbits of information – indeed almost anything. Appoint a wiki administrator whose job it is to organise the information on the WIKI so that it is easy to find, intuitive and consistent. (Note that the WIKI is not home for formal documentation.)
* Be agile: Have SCRUM meetings, use information radiators, etc
You can almost guess where this customer was when these points were written. And I certainly could have gone on. The good news is that they have since totally re-invented their developer culture for the better. But I do wonder how many firms lack any discernible developer culture - one that fosters excellence at all levels? Experience tells me that most developers are just too busy doing stuff, with their heads down below the parapet, unable or unwilling to create time to do things better.
