Developers. You got to love them ... or else they leave you ... with a half-coded system and no documentation!

This month a somewhat light-hearted look at some common ailments that seem to afflict developers throughout the world.

All puns and bad jokes are intended. You have been warned!

Have fun

Steve

Developer Ailments

The following ailments seem to cross cultural and geographic boundaries and afflict developers everywhere.

As with all ailments, they can be recognized by their symptoms and have established cures or recommended treatments. These cures and treatments are often embedded within a process such as Feature Driven Development (see Coad Letter #70 for an intro to FDD).

As with other sorts of ailment, developer ailments may also have dire consequences if left untreated.

Ailment #1: Featuritis

"Developers can get really (really) carried away, identifying feature after feature after feature."
Java Design, Peter Coad, Mark Mayfield, Jon Kern, Prentice Hall

"Featuritis: The besetting temptation for the architect of a general purpose tool such as a spreadsheet or a word processor is to overload the product with features of marginal utility"
The Mythical Man-Month, Fred Brooks, Addison Wesley (anniversary edition)

Symptoms:

1. Developers meeting to decide on requirements without the presence of a user representative.
2. A reluctance to clarify requirements with users, to ask for feedback or ideas from users, etc.
3. Developers getting excited about a suggested feature while business experts look on blankly.

1. Feature Driven Development (FDD) defines a feature as a client-valued piece of functionality. If the client cannot put a business value on the feature, drop it.
2. Regularly review the features list with user reps. (see Build a Features List)

The resulting system contains many 'cool' features that are not really required and are of little intrinsic value to the business while many features important to stake holders are missing or only partially implemented.

Ailment #2: Technology Obsession

Developers like technology. Developers like trying out new technology. Some developers will find any excuse to use a new capability of a technology, technique or development tool.

Symptoms:

1. Over-engineered technical architectures using every possible design pattern.
2. Developers boasting about how many obscure features of a programming language or technology component they have used.
3. Unexpected use of obscure language features in straight-forward classes.

1. FDD is designed to channel creativity and innovation to appropriate points in the project life-cycle.
2. Design inspections and code inspections help avoid the temptation for over indulgence (see Design By Feature and Build By Feature).

Inappropriate application of design patterns and language capabilities leading to over-engineered code that is hard to understand, hard to use and that performs slowly.

Ailment #3: Code Rash

Design, especially if it involves producing some documentation, is not nearly as much fun as writing code, compiling, running and debugging. Some developers prefer to skip the boring design part.

Symptoms:

1. The suffering developer starts each assignment by jumping for the first solution that comes to mind and immediately starts to implement it.

After one week, progress is stated as, "I am 90% finished".
After one month, "I am 95% finished".
After six months, "I am 99.9% finished".
 
2. Developer statements like "I have to do a major refactoring of the code to cope with the next increment's requirements"
3. Many projects, activities or tasks are started; few are finished satisfactorily.

1. A feature team is led by a chief programmer who ensures that the Design By Feature process is followed. Design By Feature requires a feature team to think through the sequences of object interactions needed to implement a group of features.

Poor quality code due to continual 'enhancements' to cope with scenarios not properly thought through. Schedules slip because code is not resilient to change and needs severe rework each time a change occurs or a new feature is added.

Ailment #4: Multiple Cuts and Pastes

The sufferer's idea of code reuse is to copy a chunk of code from one class or operation, paste it into another class or operation and tweak it a little to do a similar but slightly different job.

Symptoms:

1. Above average line of code production. A rapidly increasing number of lines of code count for a project does not necessarily mean good progress. It could be a sign that cut and paste coding is being employed.
2. Simple changes taking a long time to be completed.
3. A change working in one scenario but not working in another similar scenario.

1. Feature teams executing Design By Feature identify and agree on proper opportunities for reuse and refactoring.
2. Cut and paste coding styles can be easily spotted during code inspections.
3. For stubborn cases, ask the offending developer for a minor change that requires code to be modified in all pasted copies. Repeat until cured.

Progress is harder and harder to achieve as more and more code needs to change with each new iteration. The system becomes bloated with an overly large code base. The code is time-consuming to modify in response to changes in requirements and is often less efficient than code that is factored properly.

Ailment #5: Panic Delight

Sufferers derive a perverse sense of pleasure at the identification of a requirements or design flaw. Normally, the problem identified is not nearly as bad as the sufferer initially suggests.

Symptoms

1. Statements like, "I have found a new requirement that breaks everything we have done so far."
2. Statements like "We need to add a whole new set of classes to the core model to cope with ..."

1. The only suggestions I for this is too point it out in the hope that a behavior modification will occur. Most good developers will recognize this in themselves over time and adjust accordingly.

If left untreated:

This leads to frustration within the team leads at continual false alarms and distractions. Also, a potential 'Cry wolf' situation can occur where a genuine bad flaw is ignored because it is thought likely to be a false alarm.

Ailment #6: 'My Way' Addiction

It is much 'cooler' to build something yourself than integrate somebody else's work. Sufferers go out of their way to do the former instead of the latter.

Symptoms:

1. Given a piece of code to enhance, extend, or fix a developer says something like:

"The code is totally incomprehensible. I have to completely rewrite it all."
2. Ask for a feature common to many systems a developer says something like:

"There are no components that do exactly what we need so we need to write our own." or
"it will take too long to find an existing component and learn how it works, it will be quicker to write our own."

1. Tools like Together can reverse engineer existing code into class and sequence diagrams to help understand the structure of the code.
2. Automated audits and metrics (Together Control Center) can also help identify weaknesses and bad practices.

Note: this can also be used by the developer to properly justify a rewrite.
3. FDD's feature teams mean that there is less opportunity for pride to rule over pragmatism because the team owns the results instead of one individual.

Resources and time are spent on constructing components that are likely to be less efficient, have more bugs and be less extendable than established components purchased from a third-party.

Ailment #7: Over Complex

Sufferer's revel in complexity and complicated designs because it makes them feel clever. Often a simple, elegant design does the job as well if not better and is easy to extend and enhance. However, a simple and elegant design often takes more time and thought to discover.

Symptoms:

1. Class diagrams that look like maps of the London Underground train system.
2. Multiple layers of proxy, facade and decorator design patterns in a technical architecture.
3. Over general classes with many, many constraints to provide correct behavior in each scenario.
4. Absolutely everything is configurable or data-driven.
5. Impossible scenarios are catered for.

1. When building an initial object model, split into sub-teams, each produce an object model snippet, compare and contrast and agree on a preferred solution.(see Develop an Overall Model)
2. When designing a feature, use a feature team so that multiple minds are applied to the design.

Time wasted on complicated code, trying to enhance and modify it. Can lead to 'My Way' addiction in other developers if encountered repeatedly

Ailment #8:Nanosecond Nobby Syndrome

Sufferer's spend hours squeezing out slightly better performance from a piece of code oblivious to whether it makes a significant improvement in the overall performance of the system.

Symptoms:

1. Over complicated code.
2. Missed milestones.
3. Slow rate of feature completion.

1. Holding developers accountable to deadlines is important to reduce the time available to do this sort of optimization.
2. In FDD, Chief Programmer's work closely with their feature team members and can soon pick up on developers suffering from this ailment.
3. Feature teams apply peer pressure because a feature is not finished until all the members of the team have finished their work.

Code can become increasingly complicated as optimizations are applied. This makes code unnecessarily hard to understand and therefore to enhance, extend, etc.

Ailment #9: Delivery Phobia

This can look similar to code rash but is caused by perfectionism, insecurity or ego. A sufferer does not want to appear wrong or have flaws pointed out in his design or code.

Symptoms:

1. Refusal to claim that a piece of code or a design is completely  finished.
2. Constant tweaking, fiddling and minor enhancements.

1. FDD's feature teams mean that responsibility and accountability for code is shared among the team.
2. Pair programming should work too if the pair of developers are of equal stature within the project.

Results in frustration among the users of the developer's code because constant changes to class interfaces cause ripple effects through code they thought they had finished.

Ailment #10: Documentation Deficiency

Sufferer's believe that writing comments and documentation is not nearly as important as writing more code.

Symptoms:
 

1. Few comments in source code.
2. Useless comments like:

/** the loan application class */
public class LoanApplication {
 

3. Developer statements like "my code is self-documenting"

1. FDD mandates design and code inspections that help here if documentation and commenting are checked as part of the inspections.
2. Frequently and regularly generating documentation from the project source code ( using a tool like JavaDoc or Together ) and publishing it on a intranet can shame a developer into adding more comments to their code ... but only if that developer is the exception and not the rule.
3. You can also run comment to source code ratio metrics by developer and publish the results prominently. However, lines of comments, like lines of code, are often misleading; work spent reducing a comment to a clear and concise statement is preferable to a rambling page full of vague, inaccurate, irrelevant remarks. Therefore, it is unlikely this tactic is sustainable but could be used as an initial shock treatment.

Code that is hard to understand and therefore much harder to use, enhance, reuse, extend, optimize, etc.

©2001 Giraffe Productions