Finishing a project

In my experience it is not just an artist who has trouble finding a point to lay the last stroke and call it finished. Software is a nightmare in that regard because not only does it have to satisfy the client but often also many, many users and stakeholders. Therefore, finding a solution is difficult until you're almost at the point of completion, where you say "we've satisfied the requirements, we're sick of this software and you're sick of waiting, it's finished".

So how do you not only finish a project but finish it to spec and on time?

First point is obvious... get the spec right. If the spec is right then a solution will be the point at which the spec is satisfied. Some problems will make do with a solution which satisfies the spec. But how often is a spec written which encompasses both something that can be verified and something that the client wants? You can make a spec so that it can be a checklist and every requirement can be ticked off and verified... but will that mean the software produced will be useful to the client?

I think this is why iterative processes come to the fore. They accept that you cannot get the spec perfect and build the perfect system. Can't be done, 'cos software invariably deals with "problems" or "messes" and not "puzzles". Iterative says we'll get what we think is right done and then we'll assess it and changes can be made and new functionality added. It does this by reducing the temptation to change things on the fly... "just wait 'til the next iteration, we can do it then"... rather than with a conventional approach where if it's not implemented now it's not implemented.

But does that help you finish? It may not help you finish, but the changes will be implemented in an organised and planned fashion rather than continuously tweaking this and that to get it to a state of acceptability.

I still haven't learnt how to finish a project properly without just coming to a point and saying "it's done" 'cos to improve it further wouldn't be economically viable. But then that's half the fun. If all the projects were just puzzles then life would be boring.

Puzzle, Problem, Mess

Looking at three types of problem...
A puzzle has an agreed formulation and an agreed solution.
A problem has an agreeable formulation and an arguable solution.
A mess has an arguable formulation and an arguable solution.

Bear with me. (aarrgghhh claws!)

Puzzles are easy because there's a clear and set goal and a clear and set solution. There is often one solution. So because these things are fixed, you can apply patterns (common processes) to solving puzzles.

Problems are not as easy because the goals are vague. However after some negotiation, you can find a description of the problem (or spec of the problem) which you agree on. This is still subjective (where a puzzle is objective) but it's agreeable. The solution is arguable because the solution is also subjective based on subjective interpretation of subjective requirements. To make the solution for a problem more agreeable, you can accept any of a range of solution... but it's night on impossible to come up with a perfect solution when the goals/formulation of the problem are subjective.

And on top of this we have a mess. A mess is a problem where the problem is that the problem is a mess! You cannot even define what the problem is, what the goals are. A mess may masquerade as a problem but it's actually a mess. An example of a mess is "my room is messy"... define messy... not clean, not organised, not ordered, doesn't smell good... how can you even think of a solution when you can't define what the problem is? You cannot define even a subjective set of requirements to make the required solution... the solution can never be met. This mess cannot be solved. The only way to find an appropriate solution is to define the goal differently so you are not making the room "not messy" but "ordered"... you can agree on what "ordered" is. Turning it into a puzzle is even better! "My room should have no clothes on the floor". You can define what clothes are and you know exactly whether you've solved the puzzle or not.


So... relating this back to software. It's about the requirements, the problem statement. If someone comes to you with a puzzle then you can quickly find a set of requirements and when you've satisfied those requirements you have the perfect solution. However, if someone comes with a problem then you can only make the requirements as good as possible... even then you're not guaranteed to solve the problem in the eyes of the client. It takes a lot of interaction with the client so that the solution is something acceptable for them (solving the goals that they think they wanted to achieve).
But a mess... if you can't make a mess into a problem then it's lost before it's started. Sometimes you can make a mess into a puzzle, but the odds are the solution will only solve part of the client's goals. If you can redefine the mess to a set of agreeable requirements then a project has some hope of success. If it cannot, then that's a big candidate for a never-ending project. If you can't define goals then the whole thing's a mess and it will go on like a headless chook until the money runs out.


This is an attempt to look at the concepts, hopefully something will twig in your brain about puzzles, problems and messes so it makes sense. It's nothing new, just putting names and faces to things we already know exist, but then again that's what most modelling of concepts does. It just gives structure and organisation to ideas so they can be developed further and Einstein can find the grand formula for the universe.

Week 9: Giving the client what they want

This is critical. But so often it's ignored. Can Agile help?

Week 8: Pair Programming

Pair Programming and Agile:

Pair programming, or pair development in general, is a theory of two can do it faster and better than one. The justification of using more resources (it does cost more) is one of quality more than speed. When there are two sets of eyes, generally the code will be cleaner, more readable, better structured, less coding errors, etc. Mistakes are picked up earlier and that's the key. The longer errors live in software (through the development process) the more expensive they become to fix.

But I question whether anyone who preaches the benefits of pair-programming actually engages in it themselves. I'm yet to meet someone who proclaims that pair-programming is THE way to develop software and doesn't then go and hide in their office pumping out code on their own. There are of course studies promoting statistics of higher production levels and higher quality, but I could write a report quoting statistical evidence that wearing a hat while coding increases productivity.

As well as the quality benefits, there are some appealing secondary benefits:
- peer pressure to stay focussed (less slashdot),
- improves work-related communication keeping both developers on the same page,
- adds redundancy for when one developer becomes unavailable for one reason or another,
- supplements having a high level of documentation,
- reduces the knowledge gap (if applicable)... sum of 2 brains,
- the co-driver can be actively documenting or jotting down ideas in parallel to being a second pair of eyes.


Pair Programming and me:

It's said that pair programming is not so effective when both members have a similar skill level. However, in my experience it's the opposite. When two developers have a similar skill, working together and bouncing off each other can make them super-productive. Where as if you have one with a higher skill level than another, both parties get disheartened. Generally the one with more skill gets frustrated and ends up driving a lot of the time, while the less skilled developer gets frustrated that the other always comes up with better ideas and better ways of doing things making them feel redundant.

Pair programming definitely has its benefits, but sometimes it works and sometimes it doesn't. It's as much about personalities than anything else and the fluid dynamics of work relationships makes it hard to predict when it will and wont work. If you intend to pair program, then there should be a backup plan for if it doesn't work out. It's not particularly a process failure, just one of the many variables due to human behavior.