Methodology

 
“In preparing for battle I have always found that plans are useless, but planning is indispensable.”

Dwight David Eisenhower quotes (American 34th President (1953-61). 1890-1969)

“A good plan violently executed now is better than a perfect plan next week.”

General George S. Patton quotes (American General in World War I and II, 1885-1945)

“Plans are only good intentions unless they immediately degenerate into hard work.”

Peter F. Drucker quotes (American Educator and Writer, b.1909)

As a signatory to the agile manifesto, I am a firm believer in its 4 guiding principals:
  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan
I believe that a development methodology should not be heavyweight nor get in the way of delivering working software quickly to the customer. Despite the myths, Agile is highly disciplined, and when done properly, requires a number of practices to be carried out, like test driven development, and continuous integration. However, the focus is always to deliver working software to the customer, first and foremost.

I like to work in a breadth-first fashion rather than a depth-first fashion. This is also known as the 'tracer-bullet' approach, and fits in very well with iterative development. This combined with aggressive refactoring allows software to evolve as the client's needs change.

I'm also a great believer in reversibility. Basically, this principal is similar to the 'last responsible moment' practice. Basically it means that you defer making architectural and design designs concrete until you have to. This contrasts with BUFD (big up front design) where the decisions about the software's architecture and design are cemented at an early stage in development. Reversibility is about making decisions (or deferring decisions) so that options are left open when building software. Reversibility also allows for design mistakes to be corrected. This can be more difficult and expensive when using BUFD. Reversibility can be as simple as something like the decision to use an ORM for the data layer rather than using stored procedures or a proprietary data layer which locks you into a particular architecture very early on in the development process. Reversibility can also mean developing to interfaces - by abstracting key aspects of a design to simple interfaces, the implementation becomes abstracted away thus allowing the different implementations to be made in the future if desired. Reversibility is all about keeping options open to enable the software to evolve software as a client's needs change.

Another thing I feel strongly about is keeping architectures simple. Often there is tendency for architects to 'over-architect' a system. This includes trying to 'over-layer' system, to including every known design pattern, to using as many complex frameworks in interesting ways, just to give the impression that architecture==complicated. To me, architecture is simply defined as the set of high-level decisions embedded in a system to ensure that all the non-functional requirements are met and the project delivers required user functionality on time and on budget. There are always many ways to skin a cat given a set of requirements. Non-user requirements like scalability, security, performance are some common ones which are important when making architectural decisions. To me though, maintainability is one of the most important, and that is why I always think about the maintenance aspect when making a design decision. There's no value in over-architecting a solution when the project costs blow out as a result.

In my experience, the use of simple, light architectures, together with an aggressive attitude to refactoring, and an embrace of reversibility in the design lead to systems with a far lower degree of 'code-rot' - a symptom of complex systems where the code quality has diminished over time to such a degree that maintenance of the system becomes progressively more expensive.

Utilizing modern languages, platforms and frameworks, it is possible to get working software built in hours rather than weeks. . Building prototypes and iterative versions of systems is now a lot quicker than it was 20 years ago when traditional approaches advocated the 'measure twice, cut once' philosophy. This philosophy although relevant in some projects, has less relevance in the enterprise application and business software world, where the key drivers are (a) change and (b) time to market. Using prototypes and delivering working software in iterations allows clients to see and try out working software. I've always found this far more useful for getting feedback than asking clients to commit their requirements to paper. Using this tight feedback loop, real business value can be added to the software, and by the end of the project the system does exactly what the client wants. Ultimately, the client is happy.
David Barone, 14 July, 2010, 12:24 pm
Last Modified: 30 August, 2010, 8:03 pm