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.

Week 7: Working together

Once again, I had hoped to write about puzzles and messes, but my quest for more content has pushed it back another week. In the meantime, staying on the topic of the social side of software development teams, here are my thoughts on working relationships for small teams.

You generally find teams with many members are broken down to smaller, more manageable teams. This works for several reasons, such as: letting people specialise and build up knowledge in one area, giving people more responsibility/ownership over sections of work, and dividing up the team to match the architecture/model of the product. But I'm more interested in how to manage those teams once they've been formed and setting up good work practices to get the most out of them.

The management view...
In a large project there are generally several teams. The 'why' factor (see week 5) demands that team members are aware of what the others are doing, but not to the point where they're distracted from their own work. Firstly, setting up the teams to have as few dependencies on other teams' work as possible is a big plus. Then managing the teams independantly also becomes an issue, trying to keep the work seperate but keeping them in sync and driving them towards the overall goal.

The sub-team view...
This is where the fun stuff happens. A sub-team is focussed on its individual goals. To have 4-5 people working towards those goals is in itself a logistical dilema, but can be effective with the right procedures in place. Assuming a harmonious dynamic (see week 6), there are certain ways to get the most out of the team.

Pair programming is a tactic used now. Its effectiveness is arguable, but for complex software and when used in conjunction with techniques such as test-driven development (TDD), its benefit is amplified. This has sub-conscious benefits such as: a pair has a better chance of comprehending where their work stands in the greater picture (better direction) and there is more immediate communication which improves the general flow of information within the sub-team.

Having an open-plan work area is another tactic. Some team members respond better than others to this. People generally like to have a physical barrier between them and the outside world while working. There are issues with sound and distractions, but significant benefits as well. Team members dont feel as 'out-of-the-loop' when they can eaves-drop on conversations of other members, which keeps everyone in touch with what's going on with other work in the team. They can also help out when a problem arises that they know how to fix. Open plan also encourages members to share their problems, work at a more steady pace and not lock themselves away where no-one can see them playing games... so they read slashdot instead. It's generally a bad idea to sit management in the same room unless they have knowledge to offer and a non-threatening manner.

There are pros and cons, but those are a couple of ways of improving the inner workings of a small team. Generally the more contact, the more communication (formal and informal) the better.

Next week, problems, puzzles, messes.

Week 6: Team structure

There are 3 important aspects to a productive work environment (employee satisfaction):
1 - The people
2 - The site
3 - The work

Each can be broken down further, but focussing on the people side of thing we have:
- organisation structure/hierarchy
- team structure

Drilling down further, we can break the team structure (the immediate team of usually 2-10 employees working on a single project) down to:
- size
- skill level of individuals
- experience of individuals
- knowledge level of individuals
- personality

Successful teams are usually small groups of employees who have a good understanding of each other. Knowing the individuals in your team is critical to the success of a team. Everyone knowing the strengths, weaknesses and nuances of each other person will have many benefits: planning, communication, productivity, cohesion, etc.

If everyone knows what everyone else is doing, it's easier for the individual to see how their work is contributing to the whole, which helps them to see "why" they're doing what they're doing as well as helping with the 3rd factor of employee satisfanction (above: 3 - the work).

Whether it's best to have a good mix of experienced & inexperienced employees working together is arguable. The same goes for skill and knowledge levels. Often there's not a choice one way or the other, you only have the personel infront of you to choose from (as a manager). However, these aspects do affect the overall successfullness of the team. It is important for the 'why' factor to have employees working not just in their own field. If there's a technical and logical side for instance, a technical-guru should be involved with the logic side of things (even if it's just through the logic-guru presenting a fortnightly summary of work done during a meeting), and vica-versa. This not only keeps everyone on the same page, but increases the knowledge level of all employees (again: factor 3 - the work).

And then there's the personalities. This is a wildcard, but I've witnessed 3 types of interaction.
1 - the team instantly gels and form solid relationships from the start.
2 - the team cannot get sorted and never really get on.
3 - some team members hit it off while one or two remain 'outsiders'.
4 - it takes a while for the team to gel, but given the right social environment and targetted encouragement they eventually form good working relationships.

The first is obviously beneficial. The second can be disasterous and result in the team being segregated, unwilling to work directly with one-another and each person going off and working on their own part in isolation. It's parculiar, but in my experience, the 3rd is the most productive. The dynamic is often that the 'outsider' becomes isolated and puts in a lot of work, which in turn puts pressure on the others to become more productive (good motivation). However, it's a delicate situation and carries the greatest risk of everything falling appart.

There are infinite variations on the 4th and it's probably the most common. But if the people are willing to work together and have a good attitude towards the success of the project, it can be just as effective as a 100% coherant team. However, it would probably not have the longevity of a team who is 100% coherant.


A good team dynamic, recognition of the team dynamic and appropriate proactive management of the team, can make the difference between a team who fall appart after or before one project is completed and a team who stay together for several years. It's a major part of each team member's life satisfaction and is regarded in many organisations as THE most important thing to focus on. Particularly large organisations.

Week 5: the agile why

It's not a concept that's bound to agile methodologies, but it is appropriate none-the-less. "Why am I doing this?" It's appropriate to agile because in an iterative process it's easier to get sidetracked. Detours, getting stuck on minor details, can potentially damage the timeline of a project.

More important than the time allocated and even the quality of the work is a consideration of the purpose of what you're doing in the context of the project. Is what you're doing working directly to achieve a goal?

A thoroughly planned out and managed team should have less trouble identifying work units on the critical path. Identifying those work units when you have your head buried in the software in the middle of an iteration is tricky. But if the answer to "why am I doing this?" points directly to a requirement then doing that work now is likely to be justified.

This is particularly useful in our BSE team project. With 12 people and loose management & requirements, it's important to frequently ask why you're spending time working on your work unit and how much time you're allocating to it in the context of the iteraction. Without asking the 'why' question, it's all too easy to put your head down and later discover that you've wasted a day's work and you're no closer to the goal.

Week 4: Week too?

Skipped a couple of weeks, but it's just a change in standard.

Doomed from the start
It became apparent at this week's lecture that we (BSE final year project) got is all wrong from the start. Heading out to visit the client with a massive knowledge gap and little requirements gathering experience was a recipe for disaster. I think we knew it at the time, but we let it slide.

12 people all smiling and nodding, taking some sort of notes from vague scribbles to word-for-word exhaustive dictation. We didn't have a plan for the session, we were not prepared and we got out of it exactly what we put into it. We went in without structure and a mind to catergorise, watch for 'pain points', problem/solution space or form/function. Our client didn't know what they wanted but they knew more about it than us, so we were in no position to direct the meeting. Due to this, we followed their lead and that directed us away from a "develop this product for us" type development-based project to a "show us as much as you can about this stuff" kind of research/analysis project. Had we had more domain knowledge at that time, we could've directed them down the develop us a product path and right now we'd have a solid product to do exactly what they wanted in the first place instead of patching together 3 pieces of software to give them a seemingly hacked together product where the most intensive part will be making the GUI solid.

We had little practical training in (or agile methodologies for) requirements gathering. The first exposure to it was when Raj walked into our LSSD lecture and started logically plotting out requirements into categories and laying out a plan for structuring the way you think about requirements. But the damage had been done and we were on a colision course for the situation we're in now. Had we got that initial step right, it may well've got us a solid development project, which would in turn have made the entire project far more interesting and negated some of the motivation problems within the team.

Shows the impact of one early step in the Software Development Life Cycle on a project. Especially as it was related to client interaction.