Developers. You got to love them ... or else they leave you ... with a half-coded system and no documentation! Therefore, this is 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!

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

This is an updated version of a somewhat light-hearted look at some common ailments that seem to afflict developers throughout the world. Originally written for the old Coad Letter newsletter, all the cringy puns and bad jokes are intended. You have been warned!

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 .

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."
  Peter Coad, Mark Mayfield, Jon Kern, Java Design, 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"
Fred Brooks, The Mythical Man-Month, Addison Wesley

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.

Cures:

  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)

If left Untreated:

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. Additional unnecessary features add to the complexity of the system making it harder to learn and harder to use. This in turn, can make user acceptance of the new software harder. Additional unnecessary features increase the amount of testing required or, as is often the case, the amount of testing remains the same but the coverage of the testing is significantly reduced.


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.

"When I was a young journeyman programmer, I would learn about every feature of the languages I was using, and I would attempt to use all of those features when I wrote. I suppose it was a way of showing off, ... Eventually I figured out that some of those features were more trouble than they were worth. Some of them were poorly specified, and so were more likely to cause portability problems. Some resulted in code that was difficult to read or modify. Some induced me to write in a manner that was too tricky and error-prone."
Douglas Crockford, Javascript: The Good Parts, O'Reilly

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.

Cures:

  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).

If left Untreated:

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. It is often more fun to write more and more unit test code even than it is to think through a design, for example.

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.
  4. Considerable amounts of time spent writing and rewriting automated unit test code.

Cures:

  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.

If left Untreated:

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.

Cures:

  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.

If left Untreated:

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 ..."

Cures:

  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."

Cures:

  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.

If left untreated:

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: Dual Screen Abuse

Providing developers with dual screen workstations can boost their productivity but only if the facility is not abused. If the majority of the time, the second screen is displaying an e-mail client, instant messenger discussions, or unrelated web site pages, then the benefits have been totally undermined. Now the second screen is actively distracting the developer from their work and interupting 'flow'.

Symptoms:

  1. Rushed, poor quality designs and code cause repeated failures of design and code inspections.
  2. Stupid mistakes caused by constant interuptions.
  3. Unit tests being run almost constantly so the web can be browsed 'while waiting for tests to run'.

Cures:

  1. FDD feature teams usually produce enough peer pressure to stop this.
  2. If peer pressure is not enough, a Chief Programmer or the Project Manager needs to address the issue head on, either aas a general statemnt to the whole team or in a quiet chat to the developer on their own.

If left untreated:

Poor quality code with stupid mistakes makes code inspections longer and more painful.


Ailment #8: 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.

Cures:

  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.

If left untreated:

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


Ailment #9: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.

Cures:

  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.

If left untreated:

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


Ailment #10: 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.

Cures:

  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.

If left untreated:

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 #11: 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"

Cures:

  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 Doxygen ) 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.

If left untreated:

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


Send any other suggestions for develoepr ailments to stephen.palmer@step-10.com. If I like them I'll add them to the list with a suitable acknowledgement.

Follow me on Twitter...