I’ve tried to write this post before https://andywootton.wordpress.com/2015/07/07/software-life-cycle-part-2-from-craftsmanship-to-computational-science/
but I just answered a question about ‘software engineering’ on LinkedIn and I’m pleased with the brevity:
Agile software development is the application of the scientific method to understanding the requirements for a software product. Each iteration is an experiment to confirm a hypothesis of what the customer should really have wanted at the beginning, if they’d known what they know now.
This post refers to a technique often used in Agile software development, including within the Scrum framework. It is not an introductory text so not recommended for non-agilists.
‘user-stories’ are classified as: Must (do), Should (do), Could (do) and Won’t (do), known as: MoSCoW. User-stories are then usually prioritised by an integer representing value, which represents a calculation of return on investment, or benefit:cost.
Paul Oldfield, Chief Referee at LinkedIn ‘Agile & Lean Software Development’ group said:
I find a bit of a problem with MoSCoW – distinguishing between “Must have eventually” and “Must have in release 1”. Get beyond release 1 and a high value “should have” can be prioritized in front of a low value “must have”.
And then, a lot of the “must have in release 1” turn out not to be, if we look closely.
“If you want all these in release 1 you get nothing for 6 months.
Or you can get these in 2 weeks, those in 4 weeks… would you like that?”
I gave (a slightly worse version of) this reply:
I think MoSCoW is about ‘importance’ not ‘urgency’.
Urgency comes into the prioritisation choices when the benefit of the story is time sensitive.
Delivering benefit early starts summing value for longer, so total value delivered in the life-time of the product or service will be higher but now we’re talking about delivering a different absolute ‘spot value’. Putting it another way, value can be a function of time.
e.g. “If this isn’t ready in 2 weeks then we’ll be fined by the regulator” or
“We need this before the Summer Sale starts. If you miss that, it’s useless until Christmas.”
I didn’t know this before today. I’m sharing the idea in case it helps someone else or they can improve it and give me a copy. It’s how things worked before science had to make a profit.
I ‘done a speak’ at Ignite Brum recently.
I have a rational fear of public speaking to large audiences. I decided to face it. At ‘Staffs Web Meetup’ I gave a fairly techie 10(/20) minute talk about Ted Nelson’s concept of intertwingularity. When I saw a plea on birmingham.io for speakers at Ignite Brum to replace others who had dropped out, I imagined my usual cluster of geeks in the upstairs room of a pub, not the lights/action/movie comedy glamour of the stage at The Glee Club. I’m all for a bit of clubbing but I was well outside my comfort zone.
‘All I had to do’ was reduce my talk by 75%, simplify by about the same, for a general audience and produce exactly 20 slides that would auto-advance every 15 seconds. It was described by someone on the night as “Powerpoint as an extreme sport”. That was a true story. I recommend the challenge as an exercise for the reader. It is hard work in preparation and frantic in execution but it doesn’t give you much time to panic about the faces looking up at you; anyway, you’re blinded by the spotlights.
Watch as I drop behind the pace set by the projector. My best joke and some local politics was lost in the bunching on the corners but I present ‘Everything is Deeply Intertwingled (Smash the Hierarchy!)’
Thanks to @iamsteadman for allowing me to try this and making the video available (I’d never have agreed if I’d known that,) the other speakers and the people who made us all feel welcome: @probablydrunk, @carolinebeavon, @grunt121 and the audience.
I discovered something alarming yesterday: social media is losing to messaging.
There must be a drift back, from open collaboration to closed channels, from thinking in the open to “Can I have a word in my office, please?”. It isn’t healthy for anyone to be in control of The Message, or for conclusions to have been agreed before meetings begin.
Everything I have done in the last couple of years has led me towards networks, away from the control mechanisms of hierarchy. Please let us not give up now, just because being more open is harder work for dishonest people. If good team players are better, imagine what the awesome creative power of players in multiple teams with overlapping goals could achieve.
[ This post is a version of my reply on LinkedIn to a post by Euan Semple,
‘A Plague of Managers’ (upon your WikiHouses?).
See: https://www.linkedin.com/pulse/plague-managers-euan-semple ]
There’s an interview with Jimmy Wales of WikiP in CMI’s ‘Professional Manager’, Winter 2016. He says a manager has five functions: planning, organisation, co-ordinating, commanding and controlling. Wales would like to change the last two functions to: inspiring and coaching.
The ‘Agile movement’ is pushing the remaining three functions towards fluid planning and self-organised, networked teams rather than hierarchical power-structures. That suggests to me that the only function left is picking sufficiently inspirational strategies to keep the attention of your teams and to meet their coaching needs. It seems an environment in which teams should be appointing their managers.
If I was a manager, with no remaining knowledge of ‘how things are done now’ myself, I’d be fighting against all this modern nonsense and trying to maintain the status quo; lashing myself in position at the top of a tree made of single-points of failure for information flow, so that I could cut off any branches as threats emerged.
Ah… I see!
This is not my late entrance into the Unix editor flame wars. I’ve always disliked vi and emacs about equally. I’m sure that both are amazing if you have a memory and use them every day. I don’t. I am, however, interested in computational models. The Unix ‘small pieces loosely joined’ philosophy had always leaned me towards vi. I knew emacs had ‘Lisp inside’ but I didn’t care. I had a bad experience with Lisp at university, but what really put me off was that emacs isn’t just an editor; it’s an environment. It duplicates things that happened elsewhere in Unix. You go in there and you don’t come out until home time. In the Winter, you don’t see light. It is neither small nor loose and I didn’t understand why. Was it the first IDE?
Richard M. Stallman hacked on emacs at MIT’s famous AI Lab. The Lab and its culture were torn apart by a war over intellectual property of the family Lisp machines. It was a difficult breakup and RMS was abandoned by both halves of his family. In reaction to creeping commercialisation he started the GNU project which later enabled GNU/Linux &c.
I’ve realised only recently how incredibly unimportant Unix was to RMS. He simply wanted somewhere to run a Lisp environment that couldn’t be taken away from him, or others who subscribed to the original MIT AI hippy culture and ethics of free sharing of code and information. He ported a ‘C’ compiler to port emacs and started a movement to maintain everything else he needed.
MIT’s free educational videos contributed to my understanding of these issues. They used Scheme (another Lisp) before moving to Python to get access to more libraries. Perhaps they should move back to Clojure.
Someone told me recently that there is no point in ‘knowing’, as other people only value you for what you ‘do’. While I’ve been writing, the two have been intimately linked. I’ve experimented to confirm my hypothesis that the less focused I am, the more conceptual connections I make and creative ideas I have, suggesting that in any period of time, productivity and creativity lie in opposite directions. I grow ever more certain that creative ideas are what allows humans to make our great leaps forward, so that things we thought needed to be done efficiently become irrelevant.
Society should be more tolerant of us slackers, dreamers, artists, pure researchers, collectors of tales; those who are interested in odd things to an unhealthy degree. Productivity kills innovation. Efficiency drives stifle improvement and increase entropy.
WARNING: Too much ‘management’ may be harmful.