Mind The Aperture

Picture each software system as a gigantic puzzle — an admittedly over-simplified analogy.  Each piece, so the visualization goes, is an encapsulated component with boundaries and responsibilities.  Only when each puzzle piece is connected do we have a complete software system — the big picture coalesces on the landscape.

A problem with this analogy though — one that might reflect some of the challenges we face in grasping the true depth of problems our code aims to solve. You see, the big picture — the one resulting from an assembly of puzzle pieces — isn't a fundamental given.  We haven't anything concrete to serve as a reference picture.  How do we know when the system is ready?

Gaps In Foresight
The waterfall approach to software development doesn't work because of a fundamental misstep in presumed knowledge.  Knowledge before the construction phase starts.  Apertures inevitably rear their heads only after development has started.  If we are to assume that we won't hit these gaps in knowledge during the development of our product, we're ill-prepared to deal with them right from the get-go.

So what do these gaps represent?  Do they mean that there are serious problems with our understanding in what we've set out to build?  Do they mean that we've simply miscalculated the complexity involved?  Was our team naive in choosing the required technology platform on which our software runs?  Any one of these could be true, and the only way you'll find out is to try building it.  The trick is, if you can eliminate the painfully obvious gaps in knowledge before you start your endeavor, you can be sure that you're on the right path.

Wide gaps in foresight are preventable.  Perhaps even mid-size gaps can be identified and evaluated with no more than a little research.  It's the smaller ones to look out for.  These gaps in our assumed know-how will come back to bite us once we've put in any real development effort.  The trouble with small gaps in understanding what the software project is all about is that they tend to progress along side the project.  As the project grows in size, the components that we've designed — the interfaces that serve as the basis of our architecture — are lodged throughout the code.  And in the same way the newly-fashioned design parades through the system, establishing it's roots as the basis of which the rest of the code uses, the small gaps in our understanding take hold and forever change the future of the project.  That is, unless we can learn to differentiate between good gaps and bad gaps.

Leaving Gaps Alone
Who says all missing pieces are necessary, that all potential gaps of any software system must be filled?  I think this is another misconception that we all experience at one point or another during our lives of building software.  We have to somehow understand and implement all potential use cases of the system, including those that stakeholders have yet to consider.  These aren't exactly easy to come up with either.  We have to put ourselves in the shoes of users.  Of administrators.  Of support staff.  Anyone.

The trouble is, once we start thinking about where the requirements fall short, we start playing a guessing game.  We generally ask the whoever the gap concerns about what they want done about it — how should we implement this scenario? Chances are, they don't know.  If they'd thought about it, it'd be in the requirements now wouldn't it?  But at this point in the game, it's difficult to think responsibly about these gaps in our understanding of what the software does.  There is no system in production yet. So how does one quantify changes that should be introduced without any knowledge in how the system works in reality?

Asking a stakeholder about a missing gap in the system during development won't necessarily help you much because they need to think about it.  Or worse, no thought goes into how to fill holes in the system and it's just a workaround that plugs the gap.  In the best case, we will sit down with the stakeholder and actually think about what the gap represents, how it should be dealt with, and what are the significant architectural changes.

Keep in mind — this is still development.  We've now got a road block in place, slowing the continuous development effort.  While the issue details are being ironed out, there really isn't much that can be accomplished in terms of writing code. Pushing forward without a full understanding of what the system goals are, we could be writing the wrong thing.

Having said all that, I think it's better to leave gaps alone during the development phase.  Just as long as they're understood.  The implications of missing requirements from all perspectives of the project will enable use to move forward in pounding out lines of code.  Nothing makes stakeholders happier than a system delivered sooner rather than later — regardless of gaps in what the system does. The key is, as I mentioned, how the system deals with gaps in understanding.  If you allow for stakeholders to view a functional system, and can point out the gaps in a meaningful way, they're more apt to make the right decision and fill it with something useful.  Just be sure to produce a working system, one that knows about the gaps but will still work.  Point out the what the gap means for every aspect of the software.  It's much easier to make these arguments when you've got a running software system to back up your claims.

Developer Headphones

Agile Focus has compiled a list of signs that a development team isn't operating optimally. It is a pretty good list although I have to say I disagree with the first point.

People wearing headphones inside an agile development environment doesn't necessarily mean they are trying to block out their surroundings. Especially for developers who are writing code. When it comes to writing code, I'm a big proponent of music. Not to block out what is happening with the team, but to add some character to the software I'm building. Even if there are no external distractions happening for hours at a time while writing code, I still prefer music because the silence is distracting.

Having said that, there is a time and place for music and it isn't during collaborations with other team members. Communication is essential but so are those coding intervals where you, as an individual, get things done.

Breaking Release Cycles

There exist today endless software methodologies, each of which, allow for differing policies on producing releases. Some methodologies allow for variable length between releases while some dictate a strict cycle length. The methodologies that follow a strict release time-line are most likely using an agile approach to software development. When using this approach, the release dates for the software are one of the, if not the most, important rules to stick to.

When using an agile approach to software development, there should be a fixed amount of time between releases. This may at first seem counter intuitive. How can a development methodology be agile if the time-line is of fixed length? Agile should support change and that is indeed one of the key benefits to using an agile approach. However, not everything can change. There has to be at least some formal rules that allow for some sort of organization. If there is nothing strict in place, the practice is flawed because nothing would ever get released. And it is the continuous releasing of software that provides the invaluable feedback that plays a huge role in the agile methodology. Take a look at some open source projects that have a six month release cycle. Sure, there is feedback from the user community, but they don't see how their feedback is reflected, which, in turn, generates more feedback and so on.

With a shorter release cycle, this feedback is reflected sooner. But what about when the agile approach is used for developing a solution for a paying customer. Does their request for some change or some feature mean that the release cycle length should be changed? In almost every case, I would say no it doesn't. They are paying you to develop software because you know how to do it and constantly pushing back release dates does not help anyone. The only exception to this rule is when it is a deal breaker. If holding up the release will prevent the loss of money, you simply do not have a choice. Otherwise, there is always a good reason one can give for not including a requested feature. This is especially easy to explain to customers when you always ship predictably and on time.

Productive Developers

In an interesting entry over at agile focus, they mention the developer productivity question. They also discuss why defining developer productivity is such a hard thing to do. The question of whether or not productivity can or cannot be accurately measured is still unanswered as far as I'm concerned.

Developers have a goal to reach on any given project that they happen to be working on at any given time. Or, at least they should have a goal. If they don't have an overall idea of what exactly it is that they are building, then there are bigger problems elsewhere and the company need not concern itself with measuring developer productivity. As stated in the entry, if the developer does have a goal to reach, any forward motion made toward that goal can be considered progress. Again, nearly impossible to measure.

This of course begs the question, should developer productivity even be measured at all? Or should management be able to answer yes or no to the question of whether or not a developer is productive? That is, making progress vs. not making progress. I think this is a valid approach to measuring developer productivity if measurements are taken relative to the expected skill of the developer.

The Undesigned

In an interesting entry over at agile focus, we are given an idea of what the myth of the undesigned is all about. Well, in this context, it is all about undesigned software, of course. What this entry stresses is the fact that the act of software development is nothing but design and I would have to agree here. The main argument is that the philosophy of adding design to already-built software is fundamentally flawed. I would also agree here. This does however raise several questions as to what counts as already designed software (if you don't subscribe to the notion that all software is designed). For instance, in the context of implementation design, the actual code itself, it is very hard to add design to.

This, I think is what the author is stressing. An example of adding design to code might be cleaning up code that was previously sloppy. But is this really design that is being added to the code or simple rearrangement? I suppose some constraints must be imposed on this sort of cleaning up. This would simply be to ensure that code design doesn't take place while "cleaning up".

Not designed is indeed a bad design but designing nothing but code is also a bad design. Implementation is one thing but it is always best to keep the important, platform-independent, design out of the code and in a model of some form or another.

Agile software development

The Hitchhikers Guide to Software has an interesting post on "why the waterfall model does not work". I think he basically nailed the reasons why the waterfall approach to software development does not work. The main reason it fails is the huge amount of optimistic assumption required. There are simply too many variables associated with software development.

What makes agile software development superior to the waterfall approach? I think the name of the methodology speaks for itself. It allows developers to move ahead in the project quickly and easily. Also, as goes without saying, early feedback is invaluable to a software development team.