No Man’s Land
Having recently just read my umpteenth Watts Humphrey book on his PSP/TSP (Personal Software Process/Team Software Process) methodology, I find myself struggling, yet again, to reconcile his right wing thinking with the left wing “Agile” software methodologies that have sprouted up over the last 10 years as a backlash against waterfall-like methodologies. This diagram models the situational tension in my hollow head:
It’s not hard to deduce that prescriptive, plan-centric processes are favored by managers (at least those who understand the business of software) and demonstrative, code-centric processes are favored by developers. Duh!
Advocates of both the right and the left have documented ample evidence that their approach is successful, but neither side (unsurprisingly) willingly publicizes their failures much. When the subject of failure is surfaced, both sides always attribute messes to bad “implementations” – which of course is true. IMHO, given a crack team of developers, project managers, testers, and financial sponsors, ANY disciplined methodology can be successful – those on the left, those on the right, or those toiling in NO MAN’s LAND.
l’ve been the anointed software “lead” on two, < 10 person, software teams in the past. Both as a lead and an induhvidual contributor, the approach I’ve always intuitively taken toward software development can be classified as falling into “no man’s land“. It’s basically an informal, but well-known, Brooksian, architecture-centric, strategy that I’d characterize as slightly right-leaning:
As far as I know, there’s no funky, consensus-backed, label like “semi-agile” or “lean planning” to capture the essence of architecture-centric development. There certainly aren’t any “certification” training courses or famous promoters of the approach. This book, which I discovered and read after I’d been designing/developing in this mundane way for years, sort of covers the process that I repeatedly use.
In my tortured mind (and you definitely don’t want to go there!), architecture-centricity simply means “centered on high level blueprints“. Early on, before the horses are let out of the barn and massive, fragmented, project effort starts churning under continuous pressure from management for “status“, a frantic iterative/sketching/bounding/synthesis activity takes place. With a visible “rev X” architecture in hand (one that enumerates the structural elements, their connectivity, and the macro behavior that the system must manifest) for guidance, people can then be assigned to the sparsely defined, but bounded, system elements so that they can create reasonable “Rev 0” estimates and plans. The keys are that only one or two or three people record the lay of the land. Subsequently, the element assignees produce their own “Rev 0” estimates – prior to igniting the frenetic project activity that is sure to follow.
In a nutshell, what I just described is the front-end of the architecture-centric approach as I practice it; either overtly or covertly. The subsequent construction activities that take place after a reasonably solid, lightweight, “rev X”, architecture (or equivalent design artifact for smaller scale projects) has been recorded and disseminated are just details. Of course, I’m just joking in that last sentence, but unless the macro front end is secured and repeatedly used as the “go to bible” shortly after T==start, all is lost – regardless of the micro-detailed practices (TDD, automated unit tests, continuous integration, continuous delivery, yada yada yada) that will follow. But hey, the content of this post is just Bulldozer00’s uncredentialed and non-expert opinion, so don’t believe a word of it.
Leave a comment
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 
I think you are failing to attribute the spiral method created by Barry Boehm in 1986 where the idea is to spiral between architecture and code. I naturally use this method in my own work. I think every thing else is to extreme (in fact “extreme programming” was aptly named!!). To say the center is no man’s land is to ignore the spiral methods and its derivatives which include Bran Selic’s ROOM.
Thanks for your input Phil. I’m always failing.
I think that iteration and/or spiraling can (and should) apply to both ends of the spectrum and to the no man’s land in between – thus it’s a wash. Plan-centric doesn’t have to equate to just waterfall and agile doesn’t have to equate to just XP.
Note that my usage of “rev X” in the post implies that iteration is employed in the architecture-centric method.
One way through the confusion is to define architecture in a way that is. understand how to configure the structural components that comprise a. recurring components and recurring arrangements of these components that.
Agile or Waterfall – it’s really really false dilemma :)) Harlan Mills demonstrated that each data structure (class) can be reduced to finite state machine. Did you ever design state-machine in Agile? Why shouldn’t you do it? And did you check it if it is orthogonal and complete with Karnaugh’s map? How do you know strictly mathematically that your class with its members and functions won’t stall or enter infinite loop? You can only know that with Karnaugh’s map, but to get to Karnaugh’s map you need reduce your classes to finite state machine, which eventually means I, as a black-box software tester and test automation engineer, will be run out of job :))