Should our methods be more agile?

Last night at the Agile Bazaar in Cambridge down the street from M.I.T., I had a chance to listen to both devoted advocates of "agile methodologies", as well as software developers seeking some relief from the arduous path of their profession (admittedly, I also took the opportunity to subject said same people to many of my opinions).

Some conclusions:

(a) Agile methodologies are probably as good as things will get as long as the human mind is the primary tool for creating software. My reason: the human mind is quite limited when it comes to activities such as software development. For instance:

+ There are only so many details a human can imagine and remember.

+ Human minds prefer tangible, physical things over imagined ones.

+ For most humans, the future is a fairly abstract concept, made vague largely by uncertainty and a general unwillingness to think really hard.

+ Humans like to be given information, and when they are not given information, they tend to make assumptions.

Implicity, the agile approach advocates working with these human short-comings, rather than against them. Short iterations produce concrete software to examine and build on. Short-term target dates can be envisioned with only modest effort. Planning for a short iteration is worthwhile because everyone can see it is not wasted activity. Frequent feedback validates direction and provides information. Goodwill is fostered because developers feel management understands their situation. This is all good.

(b) For as long as we've been doing projects, we've been using agile methodologies, but our culture tends to be too negative to see this. All organizations periodically correct the course of their projects. The problem is people usually view course correction negatively (probably because of the attendant blaming), instead of embracing it. Wouldn't it be a lot more productive if everyone involved in a project accepted, nay, advocated, nay, demanded -- before the start of the project -- there be some number of course corrections during the project?

(c) Agile methodologies need to accept outside constraints, rather than to try to re-educate them. For example, what to do about certain marketing departments, which don't care about how the software is created, but only that it be done by some date months away, and that it meet all expectations? In more than 25 years of software development, I have found it nearly impossible to educate uninterested parties. All the pontificating about scrums (an ugly word; can we change it?), iterations, extreme programming (another bad term), feature driven development, test driven development, and all that is agile will do little or nothing. What works is repeatedly and consistently exceeding the expectations of such parties. What also works is to actively seek buy-in sufficiently high in an organization. Agile proponents need to teach how to work with difficult stakeholders along with the mechanics of how to carry out projects.

(d) "Your software development process is what materializes when the heat is on" (a comment by an attendee) -- This is the crucible in which we need to find a less arduous way to create software. Do agile methodologies stick when the heat is on? What does stick?

(e) It's not clear that a lot of little iterations get you efficiently to your long-term goal. It seems some longer term planning and navigation needs to be blended with short development cycles to create sort of a "scrum fractal".

For more information about agile methodologies, visit http://www.agilealliance.org.

A good sign...

One of the best indications of the quality of a programmer is their coding practice. Some of the best programmers I've known produce code almost mechanically in a consistent format which is very easy to read.

Among their practices:

Matching curly brackets in the same column. Of course an opening curly bracket on its own line generates more "white space" (more on this later). However, it is overwhelmingly beneficial to be able to visually pick out matching curly brackets by simply scanning a column, instead of hunting for the opening bracket in some random column at the end of an 'if' or 'for' statement. What's more, these outstanding programmers -- when you watch them type -- would type the curly brackets together, so they don't waste time later resolving compile "end-of-file" errors. They do the same with parentheses.

White space. I learned from an ad copy guru that the human eye and brain likes white space. Dense ads usually repel the eye. The same goes for code, and these outstanding programmers know this. They put in ample white space that makes their code comfortable to look at, and easy to read and to understand.

Also, the white space is not arbitrary -- it serves a purpose. For example, lines of code for, say, initializing a set of related working variables are like a paragraph, and should be written as a block of code with a blank line before and after. This formatting conveys a meaning that makes it easier for the next programmer to understand what is going on.

Another place where white space is desirable: after commas, and before and after operators. These spaces are akin to spaces between words. Itcertainlyisharderforyoutoreadthiswithoutspaces,isitnot?

And yes, an opening curly bracket should be on its own line. Not only is it easier to match with its mate, the white space is also naturally appealing to the eye.

Methodical coding. This practice is closely linked to a disciplined process for designing software. These outstanding programmers ask and answer the same series of questions before writing code. "What objects are involved?" "What do each of these objects know about?" "What do they do?" "What information do they share?"

This process is reflected in the code construction. First header code is written to define objects (of course, when an object class is coded, the opening and closing curly brackets are typed together). Then the data members are added. Then the access methods. Then the implementation of the methods. Aside from top-down psuedo-code during design, code is written and tested bottom-up. Magically when the coding reaches the top, the vast majority of it works, and is very comprehensible.

Refactoring and reformatting. Most legacy code is messy. Outstanding programmers don't just leave it that way -- they leave it in a readable format for the next programmer (I'm not talking about religious wars about style here, but rather about making really messy code look professional). Outstanding programmers will tell you that messy code wastes time, and the small time investment it takes to clean it up more than returns the investment.

A more extreme measure in this direction is refactoring -- actually changing the code, often to hide irrelevant detail. Outstanding programmers know that the human mind can hold only so much detail at once, and the cost of code maintainence is vastly reduced by allowing only a certain amount of detail to be in scope. Thus, rewriting code that does five things at once so instead it takes five independent passes -- in the end -- saves time, effort and money. So does replacing 27 arguments with a few "parameter" or "context" objects. So does eliminating global variables.

So if you're thinking of hiring a programmer, an excellent indication of the person's skills is the quality of the source code they produce. Excellent code, excellent programmer.