chris clarke

Circles Of Life

Continuous Integration (The way I do it)

Feature Development

Sloppy Code equals Buggy Code ?

Having witnessed a lot of bugs recently, big and small, in some legacy code - there seems to be some patterns emerging. The root causes of the bugs are often found deep inside big classes, often with some suspicious looking commented-out code and the odd TODO floating nearby. Even when implementing new features, I’ve found myself spending most of my time trawling through these larger species of classes trying to work out what they are doing. I find myself deleting chunks of commented out code and tripping over scary looking TODO’s saying things like ‘Fix this when I figure out what it should do’ or ‘Hack - fix me’. These bigger, sloppier classes are minefields for potential bugs and quicksand for productivity.

Having read Ivan and Nat’s attempt at a Real-time Sloppographer, from the Scrapheap Challenge at SPA 2007, I was inspired to come up with a similar utility for measuring Sloppiness in the way it had affected me.

mostLikelyToBeBuggyTop10.py is a quick bit of python I wrote to measure sloppiness based on the things I’ve encountered:

1. size - bigger files get more sloppy points
2. TODOs - more TODOs, more sloppy points
3. does it have a Test? - if not - more sloppy points
4. number of comments - maybe slightly controversial - but the more comments, the more sloppy points - i’ve found files with big chunks of commented out code so it’s useful for me

Sorry, some characters don’t show up, such as ‘+’, but you can get the original here: mostLikelyToBeBuggyTop10.py

Annoying Patterns: Saying what you’re about to do

This pattern is best demonstrated with a few examples:

Basically, the comment is describing what you are doing on the next line, and is just not needed.
Sometimes the comments are telling you something, for example:

Could perhaps be telling you that a method needs to be renamed:

Then the comment can be removed and it is clear what the code is doing.

Origins of Waterfall Software Development

No-one knows the exact origin of the term ‘waterfall’. It was apparently coined when someone looked at a diagram in Dr. Winston Royce’s paper and remarked it resembled a waterfall. In fact the origin of the entire ‘waterfall model’ of software development is very sketchy. It is said to originate from a misunderstanding of the paper Managing the Development of Large Software Systems, written by Dr. Winston Royce in 1970.

Artists Impression of Dr. Winston Royce.

The story goes that somehow Royce’s initial diagram of a process which did not work was adopted as what we now know as the ‘waterfall model’. And was later adopted as a US Department of Defense standard (DOD-STD-2617) in 1985 and shipped across Europe in to Government and Defence projects though NATO.

From what I understand about the waterfall model, and from what I was taught, you proceed through each of the phases once, and each phase must be completed and perfected before moving on to the next. However, reading Royce’s paper, he makes it abundantly clear, on page 2, that this is not a good idea:

The required design changes are likely to be so disruptive that the software requirements upon which the design is based and which provides the rationale for everything are violated. Either the requirements must be modified, or a substantial change in the design is required. In effect the development process has returned to the origin and one can expect up to a 100-percent overrun in schedule and/or costs.

Royce then goes on to present five steps which can help prevent such a thing happening:

1. Complete the coding design before analysis and coding begins - The paper was written in a time when there were a lot of technical constraints, on data size, execution time etc… Royce had found that these things had become problems later on in projects so he introduced this stage before the Analysis stage in an attempt to catch these problems earlier. A program designer would take part in the Analysis phase making the customer aware of storage, timing, and operational constraints.
2. Documentation must be current and complete - Royce was a stickler for documentation - he used it to try and control projects and make sure that they met requirements and interface definitions. One interesting thing he mentions is that programmers should not test their own code and in this respect he saw documentation as a kind of acceptance criteria for how the software should behave - so that a separate team of testers could test the software according to the documentation.
3. Do the job twice if possible - Royce advocated the whole lifecycle process be repeated in miniature at the start of the project in order to:
   

   … quickly sense the trouble spots in the design, model them, model their alternatives, forget the straightforward aspects of the design which aren’t worth studying at this early point, and finally arrive at an error-free program.

4. Testing must be planned, controlled and monitored - The previous three steps were targeted at uncovering as many bugs as possible before hitting the test phase. In this phase, Royce recommends some methods of uncovering more problems including code review.
5. Involve the customer - Royce wanted to involve the customer as much as possible to ensure the software was closer to what the customer wanted however, in his diagrams the customer is mainly involved during design and then at the end of the project.

Having read Royce’s paper, I don’t think the document has been misunderstood as stated from several sources, I think the versions of most projects match quite closely to Royce’s guidelines - plenty of documentation, plenty of analysis and design, strict adherance to specification documents and customer involvement missing at important points. I suspect that even ‘Doing it twice’, which seems like a good idea, has been proposed during a waterfall project, but probably dismissed as a waste of time and money.

I think Royce was trying to improve a software development process which was pretty immature at the time. The most common process which people were using at the time, looked a lot like this:

Royce exposed a lot of the hidden stuff that happened around this, including important practices such as testing. He also had a lot of the right motivation to catch problems earlier and involve the customer more. Although some of his ideas have perhaps been proven to be not so helpful in the long run.

How can an application or language be Agile?

From Interface21:

… Interface21 has taught Spring and agile J2EE to over a thousand satisfied students.

What is Agile J2EE? I’d really like to know.

If you sign up for a Spring training course, one of the topics covered will be:

Agile J2EE and lightweight containers

So Agile J2EE must be something to do with lightweight containers.

But hang on, there’s all these other things here:

‘agile + with’ at Amazon

The Yawning Crevasse of Doom

Do you want your communication between the two sides to be like a ferry boat or a bridge?

via Marc McNeill and QCon.

Annoying Patterns: The Hidden ‘On’ Switch

The hidden ‘on’ switch is a method that you need to call on an object before it starts actually working. Specifically, the object does not make it clear that you need to flick the ‘on’ switch when you start calling methods before turning it ‘on’.

A couple of examples:

javax.jms.Connection:

If you don’t call start() it will appear to be perfectly happy but nothing will happen.

org.apache.tools.ant.Project:

If you don’t call init() it won’t tell you that init() needs to be called, instead it will say something like “Could not create task or type of type: property.”

Possible Solutions?

The JMS one is quite tricky because you want set up all your listeners before you start the connection - dunno. With the ant one, you could put init() code in the Project constructor (duh) or use a flag:

Making the date

Having asked the question “Do you have much buy-in to use Agile?” to several non-Agile places, the answer has always been pretty much along the lines of - “As long as we keep hitting the deadlines.” Ron Jeffries has a very good article called suprisingly Making the Date which covers management and developer responsiblities to making the date in an Agile environment, I have to reproduce this brilliant cartoon from Simon Baker because it’s too good not to share:

However, I want to talk more about developer responsibilities in non-Agile places who are looking to make the move for whatever reason (Often because they think it will make them go faster. Doh!).

The second question you might ask is “Where do the features/requirements come from?”. The answer to this is often quite scary - especially when they say “Don’t know.”. But this is where Agile and especially Scrum will help to make those dates - you need to track down the source of features, often there will be many competing sources - which is a problem in itself, and start to find the people who can prioritize and eliminate these features (Because half of them under investigation will add little or no value whatsoever). Quick guide:

• Have a minimum number of feature sources (ideally one Product Owner)
• Have feature sources who most accurately represent the real customer

This is where the “buy-in” question becomes important because you will probably need support to do alot of these things. You need to be brave and be able to say “No” to feature Z or “If you want to add the shiny buttons feature, please talk to our Product Owner”. It’s some peoples job to get their features in the release because they’ve been told to, not because it adds value or is the most important feature, and they will fight very hard to make sure it does get in. So make sure you have that support first, and be prepared for an interrogation along the lines of this.

Making the most of your cheese

I’ve seen a few examples of projects where the primary stakeholders, or the people interested in the project’s success, seem very disconnected or disengaged with the project. I’m not talking about customers or end-users, I’m talking about the big cheese’s - the project/programme managers, the directors etc… You’ve probably seen a few examples of disconnected cheese, here are some tell-tale signs:

• You don’t know who your cheese’s are.
• They are based at a different site/country.
• They rarely walk the floors.
• They sit in an office somewhere and you never see them.
• You only hear from them when things go wrong.

This isn’t a cheese-bashing session however, from my experience the cheese’s are very interested in the project. After all they report to another big cheese who’s also very interested in the project. So, get them in, show them the workplace, show them burn-up charts, tell them how you are doing and any problems you are having. Even if they are in another country or reluctant to come in, just bring them in once an iteration, show them progress and ask them for help if you need it. Your goals and your cheese’s goals should be tightly aligned, make sure you are with the right cheese. In my experience, cheese’s will be very interested in what and how you are doing, and they can even help remove barriers which have been slowing/blocking your progress.

Make the most of a big cheese, they’re often corporate angels in disguise.

GNUs Not U 4

Here’s a puzzler. Minimize the following command which looks for multiple entries of a command in the PATH environment variable:

echo $PATH | awk 'BEGIN { RS=":" } ; { print; }' | xargs -I{} find {} -name ant

You could use which:

which ant

But that will only return one answer.

Could use locate:

locate ant

But that will return things not in the PATH.

Could use whereis:

whereis ant

But that only looks in a list of standard linux places, the PATH may be unconventional.