Pragmatic Dictator

The act of design includes:

• Consideration of many possible technology options
• Examination and identification of constraints
• Thought about the pros and cons of using various patterns and styles
• Comparing various splits of role and responsibility
• Looking at various tradeoffs of complexity versus function
• Formulation of opinion on possible future directions of system growth

A large proportion of this information is lost when the design document is written, because the focus is typically on providing a (notionally) definitive view of how a system should be structured which might be in the form of a bunch of UML diagrams or merely a collection of Visio-type diagrams and explanation of what each of the boxes in the diagrams does. At the code-level there is almost no chance that any of this information will have been retained. Yet this information is of high value since it:

• is the explanation as to why a design is the way it is
• provides reviewers with a clearer view of what was and was not considered
• forms the basis for assessment of the maturity of a designer and can be used for coaching/mentoring
• can provide insight for those with less experience
• contains assumptions which if breached by changes in circumstance would dictate a re-design
• dictates to a large extent how suitable for purpose a design might be

Thus I believe It’s important to expose elements of the act of design via documentation alongside the design itself, conversations during the design work etc.

Some of the more common software development mistakes I’ve seen…..

Ignoring the triangle – The triangle represents a trade-off between three core elements of software delivery – resource, product (features, non-functionals, quality) and schedule. One can only ever control two elements, the third being determined by the decisions regarding the other two. So if one wishes to dictate product and schedule, sufficient resource must be made available to complete the task in the allotted time. If one wishes to dictate product and resource, then the schedule cannot be limited. It is simply “as long as it takes”. And if one wishes to dictate resource and schedule, then product features, quality etc must be traded away to allow completion of development within the time allotted.

It’s amazing how often organisations attempt to dictate all three elements and are then surprised when a project gets messy. Of course, development processes have evolved in recognition of this trade-off – agile for example is great for prioritising, dropping features and getting something useful out the door in a resonable timeframe with limited resources.

Heroic efforts – these are a bad sign. A regular pattern of projects turning into mad hack-fests, saved by some apparently super-talented individual(s) is indicative of broken processes. One step in addressing this problem involves an honest surgery immediately after the project to determine root causes (e.g. inadequate risk management) of the meltdown and methods of prevention for future projects (e.g. regular risk review and identification of appropriate mitigations).

In the very worst cases, management actively encourages such heroism via recognition and reward. Worshipping this kind of carnage and supposed miracle recovery is tantamount to approving bad project management. Note that well-intentioned management can unknowingly drive this behaviour. From McConnell’s Rapid Development:

Some managers encourage heroic behaviour when they focus too strongly on can-do attitudes. By elevating can-do attitudes above accurate and sometimes gloomy status reporting, such project managers undercut their ability to take corrective action. They don’t even know they need to take corrective action until the damage is done. As Tom DeMarco says, can-do attitudes escalate minor setbacks into true disasters.

No Risk Management – One can never predict or spot all the risks but there are some obvious ones that get missed over and over. For example, we’re building a piece of software that relies on a component we’ve not used before. This is a big risk, one that can be mitigated by writing a test-harness or simulation of the way in which we plan to use the component.

The simulation should include realistic load, failure conditions, maintenance etc and should be as close to the beginning of the project as possible to surface any issues early (we cannot afford to wait until final QA or deployment testing). There can be no shirking here because should our chosen component fail, we will need these tests in place so we can validate potential replacements as quickly and easily as possible.

Waterfall Agile – We’re supposedly “doing” agile but one or more of the following are true:

1. There’s a fixed deadline, with fixed features and fixed resources.
2. All Negotiation/Trade-off is done prior to project commencement with no review between sprints.
3. All sprints have been planned out in advance right up to the release date with no spare time.
4. There are no risks to manage (because there aren’t any apparently).
5. No-one is entertaining the idea of unknowns.
6. When a sprint doesn’t deliver as anticipated, outstanding work is simply crammed into the remaining sprints.

A couple of false economies software development indulges in:

1. It’s quicker for me to write the code than explain the design to someone else.
2. Automated deployment will have to wait until we have more time.

Number one costs a software development team in a number of ways:

• The career development of other members of the team is slowed – if one never discusses design how does one expect to obtain good designers or architects?
• The team’s development capacity is reduced – essentially projects bottleneck around the uncommunicative heroic individual.
• The team’s effectiveness is reduced – project load cannot be divided efficiently because individuals have skills in narrow areas limiting the breadth of work they can perform.
• Team morale is damaged with other developers feeling left out, unfulfilled and unable to influence project decisions

Number two yields costs including:

• We save on some development time but the cost is re-surfacing in staff-hours required to perform the deployment.
• An increasing number of mistakes that extend deployment time or breaks releases.
• We save development time once and pay the price for that saved time with each and every deployment.
• The cost of each successive deployment increases because the system’s size is growing.
• As each deployment takes ever longer, the gap between releases is likely to increase.