Gavin Terrill's Blog

Agile Findings from the GAO

According to the GAO, US Federal Agencies spend $76 Billion bucks annually on IT so to reduce the risk of budget overruns and delivery delays Agile is now recommened by the OMB as the preferred development methodology. They've just released a freely available report on what practices have been effective, and what the challenges have been. These challenges tend to not get talked about so much so it's great to see this commentary.

Some of the biggest challenges identified were:

• "Teams having difficulty collaborating closely": Getting the mix right with pair programming, as well as personality clashes when everyone is working so closely together, spring to mind as examples of where this comes up
• "Self directed work" and "difficulty managing iterative requirements": Particularly when transitioning from a traditional project manager led approach. The Scrum Master is critical in fostering and shepherding this cultural change. Guidance around roles and responsibilities was also called out in this area.
• Setting up technical environments.
• Status and reporting tracking.
• Bringing along the rest of the organization - e.g. procurement and compliance checking.

Very consistent with what I've experienced in both small and large organizations.

10 Critical Thinking Traps & Tips

There is a great list of critical thinking traps & tips over at litemind.com. I'm summarizing them here so I remember them!

1. The Anchoring Trap: Over-Relying on First Thoughts.

initial impressions, ideas, estimates or data “anchor” subsequent thoughts

• Always view a problem from different perspectives
• Think on your own before consulting others
• Seek information from a wide variety of sources

2. The Status Quo Trap: Keeping on Keeping On

 status quo automatically has an advantage over every other alternative

• Consider the status quo as just another alternative.
• Know your objectives.
• Avoid exaggerating switching costs.

3. The Sunk Cost Trap: Protecting Earlier Choices

it's a sunk cost, and it shouldn't influence your decision

• Be OK with making mistakes.
• Listen to people who were not involved in the earlier decisions.
• Focus on your goals.

4. The Confirmation Trap: Seeing What You Want to See

looking for information that will most likely support your initial point of view

• Expose yourself to conflicting information.
• Get a devil's advocate.
• Don't ask leading questions.

5. The Incomplete Information Trap: Review Your Assumptions

(my favorite, but hard to execute!)

overlooking a simple data element can make our intuitions go completely astray

• Make your assumptions explicit.
• Always favor hard data over mental simplifications.

6. The Conformity Trap: Everybody Else Is Doing It

other people's actions do heavily influence ours

• Discount the influence of others.
• Beware "social proof".
• Be courageous.

7. The Illusion of Control Trap: Shooting in the Dark

we still tend to irrationally believe that we can somehow influence results. We just love to feel in control

• Understand that randomness is part and parcel of life.
• Beware of superstitions.

8. The Coincidence Trap: We Suck at Probabilities

Probabilities can be unintuitive.

• Don't over-rely on gut estimates.
• Beware of "after the fact" probabilities.

9. The Recall Trap: Not All Memories Are Created Equal

we analyze information based on experience, on what we can remember from it

• Get hard data. (there's that hard data thing again - see # 5)
• Be aware of your emotions.

10. The Superiority Trap: The Average is Above Average

people have much inflated views of themselves

• Be humble.
• Don't go overboard. (wrt applying rigor and rational thinking)

I encourage you to read the full article as it contains several good examples and great explanations of the tips.

What he said

Ron Jeffries:

Want to succeed at software? Then it can’t be business as usual. Study the material, do the practices, get help. Or get out of the way.

The tricky part is finding people who believe in the same values.

(via Patrick Logan)

Software Productivity Lead Bullets

Some excellent software development productivity "bullets" from Austin Wiltshire:

• Embrace the REPL Loop (one of the reasons I love Firebug)
• Dynamic Type/Type Inference
• Object Oriented Programming
• Functional Programming (this is really a tie for 3rd)
• IDEs/Text Editors (if you are comfortable using an IDE, try a Text Editor, and vice-versa).
• Frameworks (just use one!)

I would add: Get exposure to different programming languages. For example, if you are a Java developer, this is a great time to be learning Scala or Clojure.

Read the rest: The Most Important List Your Manager Will Never Read

[Test|Contract] Driven Development?

In my last post on Passion and Architecture, Eric quite reasonably asked why I think TDD and DBC are opposed?

Let me start by saying I've recently become interested in DBC again after moving office whereby I noticed my old, dog-eared copy of Object-Oriented Software Construction and thought to myself "Hey, what ever happened to that crazy Eiffel language with that cool DBC idea?".

I remembered that the central idea behind Design By Contract is that if there exists a mechanism of defining pre and post conditions and the state of class invariants, you can use static analysis to formally prove program correctness. Neat huh?

Well, not so much. The XP guys said this specification up front business may not be the simplest thing that can possibly work. Instead, you should focus on designing tests that express the system, then write code until the tests pass. The true architecture of the system will then emerge naturally, closely matching what the problem calls for, not some theoretical abstraction that has bits you won't need.

So we all converted to The Church of Agile.

Except...

People are now starting to look at their TDD projects and noticing that:

1. Their code base has nearly doubled in size (in theory, so have the number of bugs).
2. It is hard to quickly create (or run) meaningful tests beyond setters and getters, so either their velocity drops or tests are not being written at all.
3. There is a great deal of code repetition in the tests.

CDD, on the other hand, pretty much has the same goals as TDD, but with benefits... You get to use the contract as part of your documentation, and you can do that static analysis thing to verify that your program will run correctly.

So back to the question: are TDD and CDD opposed?

My answer: an unequivocal "I'm not sure".

Here is how I break it down:

	TDD	CDD
Design	Design emerges as a result of implementing code to satisfy tests. More of a "bottom up" approach to system design.	More design upfront than TDD, indicative of a "top down" approach to design.
Refactoring	Implementation can change radically without impacting existing collaborating client classes	Same assurances as TDD
Quality	"Testing can prove the presence of bugs, but not their absence" - E. Dijkstra.	Static analysis using formal verification to ensure quality is one of the main advantages of DBC.
Ease of use	Good for isolated classes. More difficult when classes collaborate with subsystems such as servlets which require mocking.	DBC is not a first class citizen in mainstream languages such as Java, so tools must be used. Quick and simple to create contracts. Unclear how DBC could be used to ensure database integrity.

At the end of the day, my instinct is telling me that while CDD could potentially do everything TDD does, the tool and first class language support could be a major stumbling block for using it as an outright replacement.

Further reading: here are some of the links I've come across in researching DBC that have shaped my thinking:

• InfoQ have a great video (skip to around the half way mark) of Jim Coplien and "Uncle Bob" Martin debating TDD & DBC.
• Testing and Language Design talks about how Python's doctest and DBC are quite similar, as well as giving TDD a good poke!
• Test Driven Development and Design By Contract - friend or foe? Lots of stuff in here that I haven't fully digested yet.
• Bertrand Myers compares Design By Contract to Test Driven Development, and thinks they may well be complementary.

Using a Control in Unit Testing

Good entry on unit testing tips over at /dev/null.  Definitely agree with the last point: "Remember that unit tests are but a small piece of the quality puzzle". One of the common mistakes junior developers make is dismissing the idea of unit testing because "it doesn't handle system integration issues" (for example).

I find the first point about having a control case interesting. I've never used this idea in my unit testing experience, but it sounds similar to the idea used in aircraft fly-by-wire control systems. They typically have several systems running in parrellel that have been written by different developers  (Airbus calls this "multiversion programming") - for fault tolerance at a hardware level, and to validate that the outputs are in agreement across all systems.  These types of systems are architected for "Byzantime fault tolerance", protecting against the possibility of misleading signals (or output values in the case of unit tests) from components confusing the system. The point is, once you introduce the idea of a control and you find anomalies, you take on the additional burden of having to decide if it is the control or the component under test that is actually broken. I am not sure our non-mission critical application warrants this level of investment, but for the right applications I can see this being a useful technique.

Roadmaps Considered Harmful

Interesting post over at 37 signals about the pitfalls of putting forth a product roadmap - "Product roadmaps are dangerous".  The comments are interesting. Here is my favorite so far:

Unless satisfying your clients involves doing nothing for a long time, in which case I say: get new clients. Or if satisfying yourself involves doing nothing for a long time, in which case you’re a procrastinator/sadomasochist and should probably get a different job.

I hate to take things out of context, so in fairness I have to say that the previous paragraph in the comment was about the virtues of doing something real every day (an agile-esque philosophy indeed I may add).

As a software vendor, I am selling the value of my product to help you with your business. As part of that, I can't remember a pitch where the prospect hasn't asked to see a roadmap. The client needs to know that you have ideas that will be useful to them after they have bought your product. I think they also want to know the product has a coherent direction. So to us, the roadmap is a useful selling tool in helping articulate the "grand vision".

Another less ingenuous use of the roadmap is to help overcome perceived shortcomings in the product - kind of like saying "We don't have that feature right now, but it's on the roadmap". Some vendors will use this tactic to wait until enough customer momentum drives the requirement over the line. Similarly, Joel's "Fire & Motion" idea uses the roadmap to drive competitors nuts as they try to keep up with your feature announcements.

Nowadays, I spend a lot of time dealing with the vagaries of implementing our software in very large organizations where the difficultly is coordinating many moving parts and constituents. I've seen the "roadmap" used as a very effective tool to get buy in from the major stakeholders.

There are lots of different ways to look at roadmaps, but I think an important thing to keep in mind is that a roadmap is simply a snapshot of what you think are the most useful things the target market will need in n months time. More importantly, the roadmap is not a project plan, so it doesn't really matter if that Data Slicer & Dicer feature slips until next February if you do something that is more relevant now.

Software Developer Cost Benefit Analysis

Perhaps the most important thing I have learned since founding a software development business, is that you should strive to surround yourself with the best people you possibly can, and take the time to create environments that facilitate the flow,  tolerate the stuckness, and minimize the interruptions. This is neatly expressed in this article: Flow, Stuckness, and Interruptions.

In addition to "being in the zone", I think there is another critical related variable worthy of discussion: the abilities of the individuals doing the work. Brooks assertion in The Mythical Man Month that in general "good" programmers are 5-10x more productive than mediocre still rings true. The actual time taken to complete a task will be highly dependent on who works on the task. Brooks went on to advise structuring "Surgical" teams, where the mediocre folks primarily provide assistance to the good 'un. I don't agree with this, and instead proffer a naive  and simplistic solution: build teams where all the programmers are good.

Of course, critics of the naive approach point out that A) it is difficult to find good people and B) the economics don't work. I agree that item A is a difficult  issue, and therefore needs to continually be one of the  primary concerns of the management team. On the other hand, I think the economics do work in our favor.

Consider a conservative goodness factor of 3 (so 1 good guy equals 3 mediocre guys), and a small to medium sized software operation with 12 developers. We can see that we will now have 4 good guys. We will say a good guy costs a third more than a mediocre guy at $120K.

Here is the math:
4 * 120 = 480
12 * 80 = 960

Wow, that is 100% difference (funny how that works huh?). So, I can have my cake and eat it too.

It gets better with the fringe benefits:

• It scales. It actually gets cheaper the more work there is (for example if you doubled the developers in the above scenario it would be costing you 960 v's 1920).
• Management and communications overhead is significantly reduced. It takes far less time to get everyone up to speed on what is being built.
• Major problems are really major problems, and are worthy of your attention - you will not be bothered with minor problems that are invisibly solved quickly with no fuss. Good people just do this. This frees up my time, and makes me (as a manager) more effective.

Someone once told me that if it sounds too good to be true, then it probably is. So, help me out. What am I missing here?

The zen of branching

I'm enjoying the latest installment of Source Control HOWTO.

Favorite quote:

Best Practice: Don't create a branch unless you are willing to take care of it.

A branch is like a puppy.

We adopted subversion for new projects several months ago and are very happy with it. Now we are about to release the first version of one of those projects, so it should be fun to see how branch/merge works out. I am always nervous about this, having experienced disasters using both SourceSafe and CVS, so let's hope for a pain free experience this time.

Useability guidelines - 20 years on

Jacob Nielsen' latest alert says that 70% of useability guidelines issued by the US air force in 1986 are still correct and relevant. Couple of interesting stand-outs:

guideline 6.2.1 recommended single sign-on.

You would of thought we would of figured this by now wouldn't ya?!  He then goes on to point out that his internal usability measurements (conducted 10 years later) found that login difficulties due to multiple sign-in requirements are the second biggest problem in intranet usability (the biggest being search usability).

Guideline 4.2.6 said to provide a unique identification for each display in a consistent location at the top of the display frame.

I still think this is useful (not to mention it makes life a lot easier for AppConnector), even if Jakob doesn't necessarily agree. I'm thinking along the lines of support here.

When you think about it these finding aren't that surprising for a couple of reasons:

1. They are guidelines, which by definition tend to be fairly generic
2. Not much has changed in terms of GUI design over the last 20 years. We pretty much interact with systems the same way.
3. And as Nielsen points, people are slow to change. Trying to introduce new useability paradigms is an arduous task.