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!
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."
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:
- Developers meeting to decide on requirements without the
presence of a user representative.
- A reluctance to clarify requirements with users, to ask for
feedback or ideas from users, etc.
- Developers getting excited about a suggested feature while
business experts look on blankly.
Cures:
- 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.
- 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.
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:
- Over-engineered technical architectures using every possible
design pattern.
- Developers boasting about how many obscure features of a
programming language or technology component they have used.
- Unexpected use of obscure language features in straight-forward
classes.
Cures:
- FDD is designed to channel creativity and innovation to
appropriate points in the project life-cycle.
- 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.
Symptoms:
- 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".
- Developer statements like "I have to do a major refactoring of
the code to cope with the next increment's requirements"
- Many projects, activities or tasks are started; few are
finished satisfactorily.
Cures:
- 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:
- 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.
- Simple changes taking a long time to be completed.
- A change working in one scenario but not working in another
similar scenario.
Cures:
- Feature teams executing Design By Feature
identify and agree on proper opportunities for reuse and
refactoring.
- Cut and paste coding styles can be easily spotted during code
inspections.
- 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:
- Statements like, "I have found a new requirement that breaks
everything we have done so far."
- Statements like "We need to add a whole new set of classes to
the core model to cope with ..."
Cures:
- 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:
- 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."
- 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:
- Tools like Together can reverse engineer existing code into
class and sequence diagrams to help understand the structure of the
code.
- 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.
- 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: 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:
- Class diagrams that look like maps of the London Underground
train system.
- Multiple layers of proxy, facade and decorator design patterns
in a technical architecture.
- Over general classes with many, many constraints to provide
correct behavior in each scenario.
- Absolutely everything is configurable or data-driven.
- Impossible scenarios are catered for.
Cures:
- 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)
- 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 #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:
- Over complicated code.
- Missed milestones.
- Slow rate of feature completion.
Cures:
- Holding developers accountable to deadlines is important to
reduce the time available to do this sort of optimization.
- In FDD, Chief Programmer's work closely with their feature team
members and can soon pick up on developers suffering from this
ailment.
- 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 #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:
- Refusal to claim that a piece of code or a design is
completely finished.
- Constant tweaking, fiddling and minor enhancements.
Cures:
- FDD's feature teams mean that responsibility and accountability
for code is shared among the team.
- 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 #10: Documentation Deficiency
Sufferer's believe that writing comments and documentation is
not nearly as important as writing more code.
Symptoms:
- Few comments in source code.
- Useless comments like:
/** the loan application class */
public class LoanApplication {
- Developer statements like "my code is self-documenting"
Cures:
- FDD mandates design and code inspections that help here if
documentation and commenting are checked as part of the
inspections.
- 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.
- 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.