Coding the Architecture - kseal

QCon London 2010

Wed, 17 Mar 2010 11:24:34 GMT

After running the abridged version of the software architecture for developers course at QCon London on Monday with Simon, I returned for the conference "proper".

QCon felt quite diverse this year, running tracks on Agile, Java, .NET, architecture, craftsmanship, design, web and mobile development, testing, and more. As such, it’s quite hard to come away with some sort of over-arching feel for what’s driving the industry at the moment. Perhaps that’s really the take-away message this year: that there are numerous movements bubbling under, but a growing sense of pragmatism over technology choice and process adoption.

However, a few candidate themes were discernible that might constitute some sort of zeitgeist.

Firstly there was the contended issue of software craftsmanship. At its heart there was a suggestion that this is about being proud of the software we produce and developing techniques to enable, and perhaps enforce, the delivery of “good code”. Around the edges was the suggestion that it was describing a walled garden, wherein development became inbred to the detriment of broader collaboration. Despite primarily being a developer, I found myself disagreeing with the software craftsmanship argument more than I expected. The argument seemed to be predicated on the assertion that we simply knew that we had a lot of bad code and that bad code was, well, bad. It took other tracks to present any evidence of there having been no improvement in software project success rates over the last decade, which may simply be bad science anyway! In a successful bit of scheduling there were talks representing both sides of the argument, so this is definitely a topic to keep watching.

The craftsmanship track was also complemented by the development and operations track. This presented a view of development, deployment and production support disciplines as a partnership, ideally wherein they were part of the same process. Craftsmanship in the output of this sort of team feels like a more valuable ambition, where the notion of code quality reflects its ability to survive outside the bubble of our QA processes.

The Agile movement also came under some scrutiny in the Agile Evolution track. There was (finally!) a pragmatic view of it presented as an industry that has seemingly sprung up off the back of some well-intentioned recommendations. In a somewhat ironic retrospective, we see how Agile has caused us to throw away things that we have since come to reinvent, while clinging to rituals regardless of their real value; “we have ADHD, retrograde amnesia and OCD,” says Keith Braithwaite. Rachel Davies, author of “Agile Coaching”, referred to "w-agile": mini-waterfall with daily stand-ups, the point at which many attempts at agile adoption stall. However, it was refreshing to see this recognised as being a good start and perhaps as a reminder that it’s not a particular process that’s the goal, but continuous improvement.

There was a huge amount in addition to this at the conference -- certainly a couple of consistent technical themes that are worth tracking down on the QCon site. In particular, Dan Ingalls provided a reminder of the enjoyment we can get from developing software and that we shouldn't lose sight of this in our work.

Also speaking at Software Architect 2009

Sun, 20 Sep 2009 19:22:22 GMT

As Simon's already indicated, we'll be presenting at Software Architect 2009 in London.

We'll be running the CTA one-day workshop and Simon will be presenting two sessions on some of the skills typically required of software architects.

I'll be presenting a session on my day (and the occasional evening and night) job, working on a financial trading application. The focus will be on the client-side architecture of the desktop application, showing a few examples of how client and server development have similar concerns and solutions, but also where they are different and benefit from different techniques.

We've covered most of these concerns in various posts on this site, from development methodology to service-oriented designs and approaches to logging. With the return of rich applications (albeit "zero install" and/or running in a browser, plugin or mobile device) it's worth considering which design decisions are based on an understanding of this domain or simply inherited from lessons learned working server-side.

The schedule for SA2009 is looking good, so hopefully we'll be able to provide an overview of the discussions and presentations from this year's conference.

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.

Style on top of substance...

Wed, 27 Aug 2008 13:12:54 GMT

As seasoned techies, many architects aren't automatically comfortable giving presentations. Ironically, our ability to abstract and describe complex information makes us better suited to doing them than we like to think, providing we understand the medium.

Presentation, whether it's via projector, whiteboard, flipchart or hand-waving alone, is an important tool for helping convey certain aspects of architectures, especially as our target audience is sometimes non-technical.

The Four Stages of Learning

Tue, 25 Mar 2008 10:07:57 GMT

I've found many parallels with the four stages of learning in software development, from how a developer's approach to design changes to how agile teams eventually become self-organising (eg, Scrum's "readiness levels"). By understanding where someone is on their path to becoming truly good at something you can be more effective in mentoring them to the next level - rather than assuming you can fast-track them right to the top.

Common sense...

Mon, 28 Jan 2008 11:21:00 GMT

I've just spent a day helping out on a project I had some involvement with last year. For some reason it apparently puts people's minds at ease when an old face gets involved (actually, my face isn't that old - perhaps I mean't "a familiar face"?)

Despite my prior involvement I can't claim to have particularly in-depth knowledge of the systems being worked with. I'm certainly not familiar with the requirements that were being discussed. I wasn't really even there to solve a specific problem. My helping-out wasn't a formal arrangement - I was there, unaccountable and for one day only.

I don't reckon there's a lot of architecture you can get done in a day. However, you can do a lot for the architecture in that day. By asking a few simple, common sense questions you can drive out what's missing, the reason that a project might be languishing:

"What methodology are you following?" Although a one- or two-word answer might result you're really asking them to prove it. "Can I see the backlog?" "Have you signed off the architecture document?" Most methodologies rely on commitment and accountability so if the team isn't clear on the approach they're unlikely to know what they're responsible for or who's relying on it.
"What problem does this design solve?" Ok, as an outsider to a project I've got to get some context, but I'm surprised how many times a solution is given as a requirement. This often indicates that a technical solution has been conceived by those undertaking the analysis - the potential for standardisation, reuse and, worse, understanding is severely diminished. Furthermore, if you don't know what the problem is, you've very little right to be confident in your solution.
"Why did you choose this solution?" Problems usually have a corresponding space of solutions, not just a single one. Understanding why a solution was reached is another step in having confidence in it. You also start to learn how reversible the decision is or how flexible the solution is and thus how much effort you might want to spend refining it.
"Can you do this?" There are numerous reasons things can't be done, particularly time, money and skills. It can be instructive to find out if the technical skills exist and, more importantly, responsibility for them seems to stick to someone in the team. Remember, the system/application needs to be built!

That's probably more than a day's worth of discussion in those few questions (indeed, it turned out to be a long day!). Whether it makes any long-term difference to the project is ultimately up to the project team.