The Keynote: Agilists and Architects — Allies not Adversaries
The talk by Martin Fowler & Rebecca Parsons, both of Thoughtworks, was about the systemic dysfunctionality, as Fowler put it, that affects the triangle of enterprise architecture, agile development and large companies. Both speakers focused more on the relationship between an EA and agile development and you can split the latter into its halves: agility and development.
Even before bringing agility into the picture, in many environments EAs live remote from the actual development: by choice (the stereotype of condescendent, I-am-smarter-than-you EA was introduced with a clip from a Matrix sequel when Neo met the Architect) or by misguided HR policies in which EAs are practically forbidden to write code. This is pretty curious, when you think of it. Computer programming is (or used to be, as Beck argued later in the day) considered as a smart, cool profession. However, inside the programming world itself, coding apparently receives a bad cloud of ‘dirtiness’. The whole white-collar vs blue-collar opposition hidden under abstract terms.
Another more subtle problem noted by the speakers is the pushing out of experienced practitioners with an unstated presumption that their time has passed and that if you are still in development in your 40s (versus, say, management), you’ve pretty much failed. It is socially acceptable to grow in skills for a number of years, but then the expectations shift to moving up the ladder, leaving coding as a ‘youth thing’.
Yet the picture is not that simplistic. In many environments, EAs do have a good grasp of the architecture their title involves. They do have a wider vision, both breadth-wise and time-wise. It would be a mistake to ignore such knowledge in favour of lower-scale goals. The problem often lies in how the EAs engage with development teams: occasional dips concluded with the dispensing of advice and diagrams are not bound to create neither trust nor a working architecture. With no trust there is no agility.
The solution, or at least a clear step towards the solution, is to have both sides making an active effort in working with the other and this, in time, should shift the perception and expectations about how EA and agile development can coexist (reading the job descriptions of 2013 will tell us whether this worked). At least, if the two parties don’t do it, no one else will do it for them.
Kent Beck’s room-packing presentation shared the results of his active efforts to capture how he designs (without any attempt to dictate this is how everyone ought to do it). Mr Beck’s initial assertion that design was hard was expectedly received with aprobatory murmurs (if both beginners and gurus say it is hard, it would be amusing to plot the perceived degree of difficulty against the skill level of practitioners. When does it reach the ‘this-is-a-piece-of-cake’ level?). Speaking of design, his recently-coined definition for it is ‘beneficially relating elements’. There is a bit of a linguistic play here: you can read design as a noun (made of elements that are related beneficially) or as a verb (to design is to relate elements in a beneficial way).
Mr Beck identified four major mental processes he uses again and again:
- leaping– a bit confusingly named, since what he meant was arguing for small steps rather than sweeping actions that require backtracking.
- parallelize approaches– not in the distributed computing sense, but in favouring the introduction of an alternative design followed by a switch-over, instead of an in-place replacement.
- build stepping stones – if you cannot get to where you want easily, think whether you can build something that will make the goal closer. There was some discussion in the room about what the difference to “small step” was
- simplification – a topic to be soon expounded in the form of a book. Kidding.
Mr Beck spoke again at an evening keynote – an informal attempt to guess the trends of computing and whether some of the staples of today’s landscape aren’t coming down from a prolonged ‘high tide’ they enjoyed in the last decades. One example: relational databases, being increasingly disfavoured for flatter approaches. Note, however, the examples were mainly from the world of Google and Amazon, and not the more typical OLTP system where user-transactions, rather than data crunching with MapReduce, are the norm (plus a ‘legacy’ warning label on the database schema :-).