Coding the Architecture - kseal

Is your development process about to be eroded?

Sun, 25 Jan 2009 14:35:42 GMT

The following quote from The Economist (Jan 3rd-9th) provides a reasonable analogy for what some development teams are experiencing as once free-flowing technology investment starts to dry up:

For the more curmudgeonly sort of older manager, the current recession is the joyful equivalent of hiding an alarm clock in a sleeping teenager's bedroom. Once again, the touchy-feely management fads that always spring up in times of plenty are being ditched in favour of more brutal command-and-control methods.

The article refers to how the relationship between old-school management and the net generation is shifting back in favour of the former's approach. While it wouldn't be correct to equate "touchy-feely" with "agile", some relationship is apparent.

I think this may ultimately be for our own good: a chance to experience how things might otherwise be done and to see whether our processes are really as perfect as we preach. Even Toyota, often cited by agile evangelists, is (understandably!) struggling, albeit far less than their american counterparts. Similarly, our software development processes will not make us immune from a downturn in business, however responsive they are to change.

As part of the interface between the business and the technology teams, architects may find themselves in an increasingly divisive position. On the one hand they may need to defend the progress (and investment) that has been made in coaching and process change. On the other, they may have to concede that lower-quality, shorter-term thinking may be required in difficult times. In either case, it would seem prudent to be proactively ensuring that your assumptions, requirements and, ultimately, the resultant process and architecture remain appropriate now that the business drivers may be shifting, if they haven't done so already.

There's nothing new under the Sun...

Wed, 17 Dec 2008 21:57:27 GMT

Ah, writing frameworks - the most noble of pastimes for experienced developers!

I've written my fair share of frameworks over the course of my career in software development: workflow, integration, content management, validation, data-binding, remoting. And with the wisdom of hindsight I think I regret having visited each of them upon the rest of the development team!

These frameworks all served a purpose (apart from scratching my framework-writing itch). They bridged a gap between the technologies we were using and the requirements being implemented, thereby making these implementation tasks easier.

However, these requirements weren't particularly unusual and the technologies chosen certainly weren't. So it seems unlikely that these frameworks were fulfilling some new purpose that couldn't be met by an existing piece of software.

These days if I find myself writing a framework I appreciate a bit of introspection or criticism to keep me honest.

Why aren't you using an existing framework?

Many home-grown frameworks (my own included) are backed up by some strong criticism of the alternatives. Much of this comes from ignorance of those alternatives or a belief that yours won't exhibit the same, or indeed any, deficiencies.

As a general rule I'd say that you really don't want to own your own framework code. At the very least you can opt to defer taking ownership by selecting an open source alternative or using professional services support for a commercial offering. This makes speculative concerns about third-party frameworks less, well, concerning.

I'm surprised how many development teams rely on open source software yet prefer to hack their way around problems (with vitriolic commentary) rather than contribute a defect report, let alone a fix! It's not just polite, it's less likely to result in regression defects.

What opportunities does rolling your own offer?

If you are writing your own framework then it pays to be clear where it's going to recoup the cost of ownership. Creating a generic solution is unlikely to be the most efficient way of meeting your requirements and moves the framework from the problem domain into the abstract, making it less intuitive to those most likely to be working with it.

Keep things no less specific than necessary, targetting your problem domain, environments and development process. Abstract where it provides clarity rather than as a precursor to world domination.

Is it too late to change your mind?

Although our architectural decisions are supposed to be costly to change, successful designs often reduce that cost, making other choices less important.

Rolling your own framework is not an ideal design decision and is simply incumbent due to a lack of suitable alternatives. The veracity of this statement should be checked from time to time as it will give you the chance to draught someone else's development effort.

It's not necessarily safe to assume that over time your framework will become better. It will probably become bigger, but since it's likely of lower quality than a third-party alternative its benefits may become outweighed by its ongoing maintenance and training costs. Improvements in the "competition" will also mean you may have to run just to stand still.

If you are intent on rolling your own framework then don't manufacture differences just to set your solution apart: they'll simply make it harder to migrate to other frameworks should the need arise.

Conway's Law

Sun, 07 Dec 2008 22:16:05 GMT

Conway's Law is an underrated, or at least, underused design observation. In short, it asserts that:

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.

In other words, the interfaces between components mimic the interfaces between the component teams. This may seem a little trivial at first, but I find it the basis for numerous significant design decisions.

Does your proposed design confound existing organisational structure?

Interfaces between internal teams are often not taken as seriously as they ought to be. It's assumed that people will talk, resolve their problems and everything will work out in the end. Even with the best will in the world, not all developers will be able to reconcile the various demands placed on them. For example, the desire to add features for one colleague whilst maintaining compatibility for another can be harder than it sounds.

Suitable design can alleviate these tensions and allow effective communication and development. Conway's Law should help keep us focused on the fact that design matters at development-time, not at runtime (so much).

Do you want to be constrained by existing organisational structure?

The flip-side of designing in a way that appeals to your communication structure is to organise your teams, or allow them to organise themselves, so that both they and the software meet an emergent structure. I believe it can be extremely productive to move developers into the same team when both sides of an integration task are being undertaken simultaneously. However, this has to be kept in check with suitable review; the emergent software design shouldn't become inconsistent or tightly-coupled as the organisational structure shifts to maximise short-term productivity.

Does your design suggest a fantasy organisational structure?

Many software systems need to be able to support requirements that didn't contribute to their original design. This doesn't necessarily suggest modular frameworks, however. The provision of a modular system is appropriate to organisational structures where release schedules can't be aligned, communication is best undertaken via SLAs and APIs or the extraction of a core set of features can demonstrably add value (ie, to more than one team).

I've seen, and written, numerous systems that will theoretically support all kinds of requirements through the addition of suitable modules. Those systems would have had to have become as popular as, say, the Eclipse IDE in order to reap any rewards from this design decision (they didn't become that popular and weren't required to). While some abstractions serve to contain complexity, others may be introduced to generate needless complexity: will your organisation ever develop your system in a way that will make your design appropriate or is the set of other possibilities more likely?

The link between design and team structure is critical to maintaining a productive development practice. It's particularly important at the level of the system architecture where the organisational structure is far less driven by the needs of your particular project but dependent on your design choices nonetheless.

London User Group - October 2008

Tue, 14 Oct 2008 13:55:18 GMT

Here are the details of the October London User Group.

Title : Testing as an Architectual Concern
Summary : In this session, Kevin Seal will present some recent experiences of testing a JavaEE project and how coverage was a double-edged sword, unit testing a blessing and a curse, and a pragmatic mix of test approaches was eventually invaluable in refining the architecture and development process.
Date : Wednesday, 29th October 2008
Time : 18:30-20:00
Location : Skills Matter, 1 Sekforde Street
Format : Presentation and discussion, with further discussion in a local pub (The Crown).
Cost : Free, but registration is required.

Many thanks to Skills Matter for sponsoring the user group.

Testing Times

Fri, 26 Sep 2008 13:09:00 GMT

Having recently taken another look at my project's unit testing strategy I thought I'd share some of my thoughts on how I see unit testing as just another force on the system's design. As such it needs to be weighed in the balance with the other forces.

Unfortunately it's a force that tends to get more influence than it perhaps deserves, not least because it's a force typically backed by the development team.