Continuous Software Maintenance aka Agile Software Development

Its widely accepted that about 40-90% of the total cost of an application is incured after it goes into production, the phase that is traditionally called maintenance.

When I'm doing Agile, not the practice-oriented farce kind, but the values-principles-oriented real kind, I don't build software in phases. I develop software in a continuous flow of activities. When I'm doing this, it feels like I'm continuously maintaining the software instead of only maintaining it after its done, and that makes all the difference.

We Don't Need No Version Number

When your delivering working software in a continuous flow, versioned in a DVCS, do you really need version numbers?

Rules-First Programming

From Just Ship, Baby by Kent Beck:

I’ve sneering dubbed this philosophy “Rules-First Programming.” I hope by naming this demon I’ll have power over him the next time he comes to sit on my shoulder. When doing things right becomes more important than doing things at all, I hope to recognize his peculiar smell, an acrid mixture of frustration, sanctimony, cowardice. “Rules First Programming,” I will say, “you better go sit on some other fool’s shoulder today because today I am going to ship.”

Right on!!

The difficulties of visualizing software

Since software is not spatial, it is inherently difficult to represent in a way that is easy for the mind to visualize.

From No Silver Bullet (PDF) by Fred Brooks:

As soon as we attempt to diagram software structure, we find it to constitute not one, but several, general directed graphs superimposed one upon another. The several graphs may represent the flow of control, the flow of data, patterns of dependency, time sequence, name-space relationships. These graphs are usually not even planar, much less hierarchical.

...

In spite of progress in restricting and simplifying the structures of software, they remain inherently unvisualizable, and thus do not permit the mind to use some of its most powerful conceptual tools. This lack not only impedes the process of design within one mind, it severely hinders communication among minds.

Stories

This post by Joel made me smile and got me thinking about an interesting way to highlight the differences between the various ways we software developers perceive what it is we do. I haven't gotten around to describing the perceived benefit/reason of the As a user, I want user story template yet, but here goes:


As an engineer,
I want to build software
so that ...

As a coder,
I want make software
so that ...

As an author,
I want to write software
so that ...

As a craftsman,
I want to create software
so that ...

As a developer,
I want to evolve/grow software
so that ...

Perfect Process, Perfect Design and Perfect Stories

From Extreme Programming Explained: Embrace Change (2nd Edition) by Kent Beck with Cynthia Andres:

In software development, "perfect" is a verb, not an adjective. There is no perfect process. There is no perfect design. There are no perfect stories. You can, however, perfect your process, your design, and your stories.