I was recently asked to describe what I felt were the traits that exemplified modern, professional software engineers. I wrote pages of notes trying to describe how I felt and why, but the most effective way I found to describe what a Sustainable Developer does is to point out the differences from the traditional (i.e. bad) way of developing code.
Traditional development practices
- new features are done as quickly as possible
- changes are done as quickly as possible
- each developer works in a single part of the code
- developers rarely talk with each other except to decide on an API
- bugs are an inherent part of having custom software
- servers and software will randomly break and we work all night to get it back up
- the tech team’s work is too volatile to do meaningful long-term planning
- bigger changes mean bigger risks
- eventually the code is rewritten because the existing codebase is unmanageable
Sustainable development practices
- Developers are a team and everyone is responsible for every part of the code
- Developers follow the Boy Scout Method: if you touch code, you must leave it better than when you found it, never worse
- Developers use emergent design and the SOLID principles to guide how code is written
- The developers will work closely with the customer to deliver exactly the feature required
- New features and changes are done in order of business priority
- Happy developers leads to good decisions – deadline pressures are detrimental to solving a problem effectively
- Code quality is never something that can be compromised; only features, time or resources are the dials to change
- Developers don’t write bugs in the first place so they never have to debug later
- Software is trustworthy; changes are never scary because the code is well encapsulated, easy to read and never “clever”
- Code will have automated unit tests over it to alert other programmers when they might be introducting an unexpected side effect
- servers are stable and trustworthy; instability and failures are rarities
- Development teams are never larger than 5-10 people; developers cannot communicate effectively to a large group
- Pair-programming is a must when training new developers in the codebase or when sharing knowledge between senior and junior developers
- Team health and current status are always clearly communicated – less “unexpected” surprises and planning is a meaningful activity
So really, this boils down to about 6 major viewpoints that differentiate a sustainable developer from a traditional one.
Stability and quality are the primary focus of Sustainable developers
Having bugs in the code is comparable to having cracks in a housing foundation; each one is dangerous and expensive to fix. Nothing unexpected should ever happen when using or changing the software.
Sustainable Developers maintain codebases for the long-term
We don’t work in churn-and-burn projects; we live in this codebase now, we better prevent an infestation of bugs. The code needs to be easy to read, easy to maintain and even easier to debug. Code that does something wrong should be very easy to spot because the code is simple, clear and concise.
Communication between the developers and the customer drives all code work
We only build what is requested, and we build exactly what is requested. Requirements gathering is a difficult part of the job, but prevents us from wasting time on incorrect or useless features.
Communication within the development team
We all have strengths and weaknesses, learning and cooperation is best for the team. Daily standups so the team is aware what others are working on, weekly or monthly retrospectives to analyze longer-term issues or to air grievances within the team are all important for keeping the developers happy and the code running smoothly.
Education and experimentation
Well-informed developers make well-informed decisions; lectures, classes, building prototypes, and research are all crucial parts of a developer’s day-to-day.
Time pressures are kept away from developers whenever possible
Effective planning is critical to keep developers from the “death march” typically associated with traditional development. Late nights and sleep deprivation only lead to bad coding decisions and bugs in the future. If a developer is informed that a feature must be out by a certain date, the temptation to cut corners to try and hit that date is large, but the long-term cost is much larger.