Over the Christmas break I read the trousers of reality, which I thoroughly enjoyed. The most interesting part for me was the chapter on deep structure. Inspired by this I produced my interpretation (a series of sketches) which in some way I see as almost mapping out the whole book (see below).
Fundamentally we need principles and feedback!
This is starting to ring bells with my current journey into lean thinking and the roots of lean and agile. I’m beginning to think they all come back to these two items, at the micro or macro scale they all involve getting a feedback loop going (or developing an existing one), guided by some simple practices/guidelines. So, if I could think of a snazzy name for it I would start a new software development methodology(?) which consists of just these elements.
Get everybody nodding at the notion that feedback is the fundamental principle on which to operate, define or pick some simple practices/guidelines, choose appropriate information to analyze and use to modify the input, keep testing and evolving the system. It seems to me the only difficult part is seeding, some activities are easier than others, unit testing has this cycle and books to hand out, whereas getting say a monolithic waterfall development process changed when your say an outsourced part is harder – But I think achievable so long as you get them to agree feedback is good and start showing them some useful big visible charts?
This new methodology, is just really a principle, a foundation, on which lean and agile are built, so its a meta-principle or a deep principle? The bit I like is its really obvious (or it is to me now I see it) and cuts through all the endless material written on these subjects, allowing people to develop systems suitable for their needs. Essentially its all about continuous improvement, get grounded principles and iterate/evolve, apply this principle to anything (software or otherwise).
As mentioned in the trousers of reality, its all recursive and fractal in nature, I’m starting to sound a bit like an insane hippy these days, maybe I am! Here are my pictures:
-
- Deep Structure
-
- Deep Structure – The Focus
“if I could think of a snazzy name for it I would start a new software development methodology”
“Evo” is quite a snazzy name for that kind of methodology.
It’s an existing fringe approach championed by Tom Gilb that sounds somewhat like what you’re suggesting. He does a poor job promoting it – I’m only aware of Evo because he spoke (rather unpersuasively, at least partly because his presentation style was “I’m right and everyone else is wrong” antagonism) at the London XP Day 2005.
http://www.gilb.com/Project-Management
I might try on those trousers – thanks for the recommendation.
Thanks Anthony, I will check out your link, research a bit and reply in an educated manner.
The more I discuss this with people and observe the world, the more I see “feedback” as one of the root principles of life and one which software engineering should openly recognise – In the way science recognises core principles. If Lean/Agile etc. had pointed out their roots clearly I would have spent a-lot less time reading endless gloss over a clear and simple message. Once I get my head around it I’m going put up some articles.
The trousers of reality is quite an abstract read, I’m not sure if I’m recommending it or not! It’s well written but does require some effort (in parts) to map it back to reality!
I have to say I was turned off by the “Evo” web-site very rapidly!
It looks very project management orientated, and not really connected with my current thinking (if it is I missed it).
I intend to write a larger article about this – The point I’m trying to make is that software engineering, like “science” needs principles. Stated, understood, universally shared and able to describe the deeper workings as we see them at this moment in time.
I think feedback should be recognised as a principle within software engineering. This simple principle drives us to explore our space further. It underlies all current “agile”/lean thinking yet it is not revealed (openly and clearly) – It is glossed over, yet used to generate more and more books and spout more and more methodologies!
We should teach feedback as one of the core principals underlying software engineering, and teach it from an early start.
This will allow people to adapt and tune their systems as required. We know the impact of tweaking feedback loops and the model is easy to explain – Just a diagram and a few bullet points. I think this is easier to explain across teams/cultures than saying “we are agile” etc. I think its a better starting point and allows people to be creative and build from what they have.
Its almost as if software engineering needs to echo science and start recognising core principles?
Will tidy my ideas and write some more on this.
I agree the Evo website is poor. The talk he gave was more explicit about how measurement could usefully drive technical projects. It was very much “decide a metric you want to optimize, and tune your approach based on the feedback that gives you”, with some emphasis on the importance of having a metric you could quantify, and not being afraid to change what you measure as your project evolves.
I think I agree that if you seek to crystallize a single essence for contemporary software development methodologies then “feedback” is a pretty good one. It’s an extreme simplification, but those are often useful.
I note that feedback is a key part of control theory, which some students of agile have touched on before. Also your talk of core principles and values reminds me a little of Beck’s values -> principals -> practices hierarchy in XP Explained 2.
“We know the impact of tweaking feedback loops” is a provocative statement – e.g. we know that feedback can lead to chaotic behavior, and to local optimization rather than global, that hysterisis and loops are often problematic in feedback-based systems, etc. It’s interesting to consider whether these give any insight into some of the problems that arise with agile.
I do encourage you to run further with your ideas!
Yes, I like the fact that feedback is well understood and tweaking the model in certain ways will have certain outcomes. I will try to pull this thread out into a clearer article.
The next question is, where would someone post a newly discovered (or hidden) software engineering principal? For science I know where to look, but for software engineering? Note I’m not saying my ramblings are new, but if they were, where would they go? Another book for a few $ or in a repository of good s/e knowledge – Which is where?
I don’t remember any principles being taught in computer science at university, do they teach agile etc. these days or do people have to escape into the “real” world before getting exposure – Must check the syllabus of a few leading s/e courses…