I’m delighted, this blog has been listed in the “20 TOP Agile Blogs for Scrum Masters (2017 edition)”.
I recognise most of the other bloggers in this list and frankly it is an honour to be classed with them.
(The news also gives me something to publish in this blog be because I’m real and truly stalled on next economics piece! Requires some analysis.)
I’m delighted – I’m in the 20 TOP Agile Blogs Read More »
“And now, the end is near
And so I face the final curtain
My friend, I’ll say it clear
I’ll state my case, of which I’m certain”
My Way, Paul Anka/Frank Sinantra
(public domain picture from WikiCommons)
Don’t panic!
I’m not going away, this blog is not finishing.
But it is changing. And with the change there will be some loss.
Blog entry 1 appeared in April 2005, and after 12 years on Blogger this blog is moving and that move has a downside.
I’ve always been happy on Blogger but in the last few years I’ve been operating three website: the blog on Blogger, allankelly.net – a static site written in RapidWeaver and my commercial site, Software Strategy (www.softwarestrategy.co.uk).
This means my efforts have been split between three sites, and Google has seen me as three sites. Given that my web presence is part of marketing my training and consultancy that might not have been the smartest move.
So last month I decided to merge the three sites and adopt a new corporate identity. Most of the move has been done, Software Strategy is now doing to allankellyassociates.co.uk, the blog is mostly moved – thanks to the great work of the folks at CMS2CMS, highly recommended – and here in lies the problem….
CMS2CMS have done a great job of moving the blog posts, images and comments. But they can’t move all the comments. That is because around October 2014 I switch the comments from Blogger to Google+. The comments on Blogger, before October 2014, can, and have, been moved across, but the comments on Google+ can’t – so all comments left since October 2014 are lost. I regret the decisions to switch to Google+ comments massively.
So many of the comments over the few years (I’m not sure exactly how many!) are about to be lost when the Blogger blog is set to redirect to allankellyassociates.co.uk.
In order that the comments are not lost entirely here are some of my “greatest hits” as PDF files with comments and the view count according to Blogger:
I could go on, I’m sorry I can’t save more comments, it is sad looking now at all the comments, far more than I thought there were. I’m also amazon by how the blog has grown, from early posts with, maybe, a hundred views to a regular audience of thousands and sometimes tens of thousands.
And I completely blame Google and G+ for this, on Blogger Google are quite supportive of blog exports but there is nothing equivalent on Google+.
O, the third site, allankelly.net, this is mostly an archive of my writing down the years and it too will disappear inside www.allankellyassociates.co.uk in the very near future – most of the content is already moved.
Blogger, Blog move & Comments Read More »
After over 10 years blogging on Blogger I’m moving.
Actually, for the last 10 years I’ve been running three websites. The blog, AllanKelly.net and my company, commercial, site, SoftwareStrategy.co.uk. This kind of made sense once upon a time but it has increasingly meant that all three sites were a little neglected.
My plan is to merge all three sites into this one eventually. Hopefully that will also benefit my Google rankings but, it also means I need to keep all those inbound links!
This is going to be a gradual process…
My last – frustrated – post finished with this line:
“banks are collecting technical debt the way they used to collect sub-prime”
I’ve always disliked the tech debt metaphor, in part because the way it is generally used is different to Ward Cunningham original defined technical debt and in part because those using it often have a simplistic understanding of debt – for example, credit card debt (which is generally to be avoided) is different from mortgage debt (which many of readers are only too glad to take on.)
A couple of years ago Chris Matts and Steve Freeman suggested a better analogy: an unhedged call option. While technically correct this metaphor required one to understand financial markets and options, most people outside the financial arena (and a good few inside it!) aren’t familiar with such concepts and so the idea floundered because the metaphor was more difficult to understand than the thing it was describing.
Still, Chris and Steve instincts were right, especially in financial arena’s the tech debt metaphor may be doing more harm than good. For a banker collecting debt is good… let me explain.
For you and me, as individuals, a debt is something I have to repay, it is a call on my future cashflow. For individuals – and many non-financial companies – a debt is a liability. As such we would rather not have it.
But for a bank a debt is an asset.
The bank holds the debt, when I take out a loan I promise to pay a bank sums of money in the future. Therefore my liability is their asset. It is two sides of the same coin.
Conversely, for a banker liabilities are things they own other people, e.g. my savings. When I place £1000 in my savings account it is an asset for me but a liability to the bank because the bank need to pay me £1000 at some date in the future. (Importantly, I decide that date and am unlikely to forwarn them.)
Bankers want more debt because debt is an asset. Debt is good.
So every time as software engineer says to a banker: “Doing it this way will create more technical debt” the banker hears “Doing it this way created more assets.”
One of the problems that occurred in the 2000’s was that banks found a new way to take on even more debt. The debt was packaged in technical ways “collateralized debt obligation” and “tranches” and such which allowed the banks to assume more debt. Things went well for a while and bankers believed they had found new way to make money. The problem was these debt packages were hideously complicated, so complicated in fact that many of those trading in these instruments didn’t understand them.
Nor did the banks own risk officers.
Nor did the regulators.
Does this sound familiar? Isn’t this technical debt?
What happened next made things worse: new instruments were divised by some of the people who didn’t understand how the original instruments were structured. In Fools Gold Gillian Tett tells of how the original JP Morgan team who devised these debt products warned as other banks introduced products which they could see didn’t make sense.
Doesn’t that sound familiar?
Doesn’t that sound like the Chief Engineer telling the Captain “She cannae take it, Captain” and the Captain doing it all the same? (Did Star Trek condition those in command to ignore the advice of their engineers?)
Banks aren’t unique here but their business model makes the problems more acute. Even outside of banking the technical debt metaphor has encouraged “debt thinking”, i.e. the idea that one can borrow from the future to get something delivered sooner and pay back later. This might be viable if we treated such debt as a mortgage which allows an asset to be purchased now in return for a long term payments plan.
However when programmers use technical debt to borrow from the future it is more like a payday loan which very quickly balloons and demands increasing amounts of our capacity (cashflow) to service the loan.
Banks are an extreme example of debt funded businesses. Most companies balance the amount of debt they take, if they need more money they may borrow it or they may ask shareholders. In general reasonable to see companies as getting half the money they need from shareholders and half from borrowing.
But banks don’t.
Banks may get less than 10% of their funds from shareholders, they rest they borrow. Anat Admati and Martin Hellwig in Bankers new Clothes explain this in detail but basically a non-financial company couldn’t do this because there is a high risk the company would go bust. But a bank can do it because in the event of failure they believe (and RBS proved) that the government will save the bank.
In other words: banks pile on debt because there is someone else who will save them if something goes wrong. (Economists call this “moral hazard.”)
It is a common business practice to borrow (increase debt) to improve returns so bankers aren’t alone in seeing financial debt as good but they are extreme.
So the question is: Do bankers believe they can take on technical debt because someone else will save them?
I can’t answer that question but clearly engineers view debt differently to bankers. Its more complex than a simple failure to understand.
Bank IT runs on a project model: as I say in #NoProjects this model encourages cutting quality because of goal displacement and the erroneous idea that it will be “done.” Even if bank managers don’t believe it will ever be “done” they can see their involvement ending, perhaps they are contractors, or perhaps they will move onto another “project.”
There are plenty of companies out there, be they outsourcers or tool vendors, who are only too happy to say their service or tool will solve the problem:
“Tech debt too high? No problem for Far Eastern Outsourcer No.1, we can fix it!”
“Do you suffer with long testing cycles? Then get Cyber Tester 3.0, it will find your bugs and shrink the cycle quicker than you can say contingent convertible bond”
As Willy Sutton is might have said: “I sell IT to banks because thats where the money is.”
So is there a way out of this?
Well, there is one more complication that might actually offer a way out.
Another dimension to banking is time: the loans that banks make (their assets) extend over the long term (25 years for a mortgage) and the bank have little power to force repayment. They are said to be illiquid – it is difficult to cancel an existing loan so you can’t turn a loan you have extended into hard cash very easily.
But, the deposits banks accept (their liabilities) are very liquid. I can get my money out of a cash machine at any time and leave the bank with less money – ever wondered why banks pay higher interest rates on fixed savings?
Some say it is this problem that banks exist to solve: turning short term liquid deposits into long term illiquid loans; matching assets and liabilities on different time scales. (Mervyn King has as interesting discussion about this in The End of Alchemy.)
When we build a software system we are building an asset.
The system itself – retail banking systems, trading platforms, risk management systems – are long term investments and become major assets. Some last decades but they are illiquid, changing systems is hard. RBS has recently aborted a demerger because of the difficult of building a new retail system (FT: RBS chief warns it may fail to sell Williams & Glyn this year).
Conversely, defects in these systems (bugs) and poor architecture (what is often called technical debt) are liabilities. More importantly, like banks financial liabilities, these can strike at any time. I can visit the cash machine today and an unknown bug can crash the system today. Similarly, a poorly designed sub-system – say there is a singleton in the system – might not crash a system but can slow down operations, enhancements and so on.
Sure these problems might not appear today, but they might, likewise I might not visit an ATM and withdraw cash today, but I might.
Therefore, let me suggest that we drop the language or Technical Debt. (Or perhaps let Technical Debt return back to Ward’s original meaning.)
Lets instead talk about Technical Liabilities:
Technical liabilities, in software, are sections of code, even entire systems, which because of their (poor) design are difficult to change, significantly hinder enhancement and are fertile ground for defeats. Such code often lacks unit tests and coherent design.
Such liabilities are highly liquid and problems may transpire at any time – impeding performance of the system itself or enhancements by programmers.
In building an asset some liabilities will be incurred. But,
Reducing the liabilities will make the asset more valuable itself and enhance the asset’s ability to change in future.
Replacing the words “technical debt” with “technical liabilities” is a small change to our language, one we can all understand easily, removes a poorly understood metaphor that is open to misinterpretation.
Technical Liabilities and not Technical Debt Read More »
If you’ve been reading my series of blogs on management it should be clear by now that I think some element of management is essential in software development. You might also have picked up that management, in various forms, is bigger than is commonly realised.
I also believe that good management can make a big difference to software development teams, I agree with Fred Brooks when he wrote:
“Some readers have found it curious that The Mythical Man Month devotes most of the essays to the managerial aspects of software engineering, rather than the many technical issues. This bias … sprang from [my] conviction that the quality of the people on a project, and their organization and management, are much more important factors in the success than are the tools they use or the technical approaches they take.” Brooks, Mythical Man Month, 1995.
Tools, technologies and processes change all the time in software development but some things last. Mythical Man Month is one such, a book originally published in 1975 about work that mainly happened in the 1960s remains, perhaps because management of software development is important.
So why is it manager-less teams do so well? Let me suggest that the value that can be destroyed by bad management is far greater than the value that can be added by good management. I would venture that sometimes no manager is better than a bad management; self-organization doesn’t so much do away with management as do away with managers.
I would also venture that the quality of management in software engineering, indeed IT in general, is pretty poor. This is especially true in the corporate IT world. The standard in software producing firms (ISVs, SIs, etc.) is generally better.
Thus is seems sensible to ask: what makes a good manager? or perhaps, what makes an individual good at managing?
Well, two things.
First, management is a skill set in its own right. Managing requires skills in the same way writing Java, Testing software or Analysing requirements does. Simply appointing someone as a manager does not automatically endowed them with the necessary skills. These skills include communication, analysis, empathy, decision making and others. It helps too to have at good understanding of the business you are working in.
And as I said in my first blog in this series, it takes an engineer to manage engineering. Someone who is an engineer, understands engineering sensibilities, the thought process of engineering and engineers and knows the issues raised in software engineering will make a much better software manager than someone who does not.
Let me quote Fred Brooks again:
“In many ways, managing a large computer programming project is like managing any other large undertaking – in more ways than most programmers believe. But in many other ways it is different – in more ways than most professional managers expect.” Brooks, Mythical Man Month, 1975.
As an industry we fail to recognise that managing is itself a skill-set, and while software managers may learn more from non-software manager there it more to it than “general” management.
But managing software engineering, indeed any form of management, requires something more than skills…
Managing requires Intuition.
That might come as a surprise to some of you but it follows directly from something I blogged about a few weeks back: Management operates in the messy, fuzzy, ambiguous “real world”. Intuition allows one to work in such an environment.
Intuition also allows for rapid decision making; an engineer, especially one schooled in agile and lean startup may often prefer to set up an experiment and test options but such an approach inevitably slows things down. Sure there is a place for hypothesising and testing but sometimes speed is more important. Plus, it is not practical to set up experiments for all the the hundreds of decisions a manager must make during a day. Sometimes having a decision is more important than having the right decision.
Intuition is more difficult to teach, it needs to be built largely from ones own experiences. Some intuition comes from having done the work which is itself being managed. Intuition is also built from past management experiences. And intuition can be enhanced in various way: self-reflection and writing to name two.
This is not to say all management is about intuition, some benefits from analysis – and that requires the skills. There is a mixture here. Let me again quote from Professor Henry Mintzberg:
“Management certainly applies science: managers have to use all the knowledge they can get. But effective managing is more dependent on art and is especially rooted in craft. Art produces ‘insights’ and ‘vision’ based on intuition … and craft is about learning from experience – working things out as the manager goes along.
…
Put together a good deal of craft with the right touch of art alongside some use of science, and you end up with a job that is above all a practice, learned through experience and rooted in context. There is no ‘one best way’ to manage; it depends on the situation.” Mintzberg, Simply Managing
That is how I see management: art, craft, science, intuition, and context dependent.
Isn’t that a lot like engineering?
Lets try that quote again with a little change:
“Programming certainly applies science: programmers have to use all the knowledge they can get. But effective programming is more dependent on art and is especially rooted in craft. Art produces ‘insights’ and ‘vision’ based on intuition … and craft is about learning from experience – working things out as the programmer goes along.
…
Put together a good deal of craft with the right touch of art alongside some use of science, and you end up with a job that is above all a practice, learned through experience and rooted in context. There is no ‘one best way’ to program; it depends on the situation.”
Do you see? – Programming has more in common with management than is commonly recognised.
Managing requires skills and intuition Read More »
Question that comes up from time to time:
“Does anyone have Agile project which is Six Sigma? How these two things Six Sigma and Agile complement each other on software product development project? “
My answer:
In theory Agile and 6-Sigma should fit, they both have their roots in the quality movement.
A cursory glance at the 6-Sigma toolset reveals similarities to the Lean toolkit – continuous improvement, root course analysis, statistical methods, so at first it looks good but…
While there are a few stories of Agile and 6-Sigma working successfully together my own experience, and the majority of the stories I hear are that they are contrary.
Let me briefly share my experience….
I did some work with a financial services company which was a big believer in 6-Sigma. Any change had to be set up as a 6-Sigma change, with a business objective, current status measurement, target, approach, etc. Its difficult to argue with such a rational position but it was hard to pull all these bits together.
The change then needed to be signed off by more senior managers as a 6-Sigma effort. And it was hard to get the necessary managers in the same room at the same time. Which meant efforts didn’t get signed off.
And with all this effort you needed to put a lot of effort into any change which meant even thinking about change was expensive.
The net effect was to freeze the status quo. Six-Sigma had the effect of preventing change not supporting it.
On a day to day level the attention paid to variance was highly detrimental. Teams adopted behaviours designed to minimize variance (e.g. differences between estimated effort and actual effort) which both made measurements unreliable and made people wary of any change, experimentation or risk. (They had bonuses related to variance reduction.)
It seems there are some big difference between 6-Sigma and Agile, if not in intent then in implementation:
So while Agile and 6-Sigma may have somethings in common they are culturally incompatible.
And as for the newer mutant form of 6-Sigma known as “Lean 6-Sigma”, well let me quote something I heard Dave Snowden say at a conference a couple of years back:
“Lean 6-Sigma is about removing all the waste that 6-Sigma introduces.”
Thoughts on 6-Sigma and Agile Read More »
Over the years I’ve build up a bit of knowledge about commercial contracts in an Agile environment. This is not something I really noticed until a few months ago when Laurence Bascle asked me to talk to the Agile4Agencies meetup group on just this subject.
Laurence’s interest came from a piece I published in InfoQ a few years back – Agile Contract Options – but more recently I published “Dear Customer, the truth about IT projects” in the Agile Journal (which later became Agile Connection). Dear Customer has become something of an ever-green, I use it as a prologue in Xanpan and it regularly gets rediscovered and Tweeted about.
So I sat down and compiled all my thinking into a presentation which I have now delivered twice and is available online. (Funnily enough, Ewan Milne did a similar presentation to Agile on the Beach 2013 also based on my original article!).
Now as some readers will be aware, this year I have been experimenting with video recordings as alternatives to the written word. I’m still learning here but after chatting with director Brian Barnes (OK, the only director I know, but a) it sounds good to say that and b) he has a new independent film out soon which need plug, trailer on that link) I though I’d try my hand at video again.
I’ve broken the Agile Contracts presentation into 11 short recordings and published them on YouTube. Each recording is between two and three minutes long:
I’d love to have feedback and comments, just e-mail me as usual. Really my question is: should I try this format again?
Agile Contracts – a video mini-series Read More »
A common piece of advice heard in Agile circles is:
“Prioritise by value. Do the highest value first.”
Sound advice, easy to say but perhaps harder to do.
And if you know me – or just read this blog regularly – you may have heard me say something like: “Estimate the benefit/value expected, measure what is actually delivered and feed this back to your decision making process: calibrate you benefit estimates, do more work where benefit is missing or change direction when it is not possible.”
I’m sure I could find more examples but I’m sure you know what I’m talking about: understand the benefit/value you expect to get – and possibly check it afterwards.
Easy really.
But there is a problem: How do you know what benefit/value is expected?
A good product manager or business analyst might be able to come up with some numbers. Good, but if you dig deep enough you’ll find assumptions or models in these figures which could be questionable. The better your analyst the deeper you will need to dig before any assumptions come to light.
As for teams who don’t have a product manager or business analyst, well, they aren’t even going to get that far before they find questionable assumptions.
Very often the expected benefit/value is a matter of conjecture and opinion.
So let me make a suggestion: Value poker.
This is a technique I’ve been using for a while and always teach it in my Agile for BAs courses. Whenever I mention it people get interested. To make it work I adapt a game-show format, specifically: Dragons Den, Sharks’ Tank if you are in the US.
Here is how you play…
Two teams.
One drawn from the people who are planning to build a product. This could be the entire development team, it could be just the product manager or business analyst with the product sponsor/champion. This team play the Entrepreneurs.
If need be this could be just one person (a product owner/business analysts/product manager) but it helps if there are two of them and if there is a whole team then bring them along too.
The second team is the Dragons/Sharks/Investors Team.
This team is probably a bigger. In a training session I usually use two teams from an earlier exercise where they have created user stories but in real life it is business managers from elsewhere in the business, perhaps product managers, analysts, sponsors and champions of other products. It could even be a high level committee – CEO, CFO, CTO, Sales, etc.
The Entrepreneurs come armed with a set of story cards – these could be in user story format, use case format or some other format, they could be epics or smaller. Whatever, the team need to believe each of these has business value.
Preferably I’d rather these cards did NOT have any effort estimates on them at this stage.
Then we set up a Dragons Den setting.
Next I ask the Entrepreneurs to pitch their product – the whole thing – to the Dragons. Usually one of the team who is a bit more entrepreneurial steps up. When the pitch is finished the dragons get to ask questions.
And we have a discussion back and forth.
Then, as moderator, I ask the Entrepreneurs for the lowest value item them have in their deck.
I take it from them and I invent a currency. This is usually named after the town I’m in, so I’ve invented Newcastle Shillings, Houston Dollars, Bath Spa Pounds or some such. Its imaginary, lets pretend I’m using London Dollars, L$.
I read out the card the Entrepreneurs gave me and make sure everyone understands what it is. If necessary the Dragons can ask some questions.
Then I write on the card L$10,000 – ten thousand London Dollars. I tell everyone about the imaginary currency and about London Dollars.
I then place the card in full view – on a magnetic whiteboard or blu-tacked to the wall, or somewhere.
I hand out the planning poker cards to the Dragons only and tell them the cards are now denominated in thousands of London Dollars. So a 1 card is worth L$1,000 and a 8 card is worth L$8,000, a 21 card is worth L$21,000 and so on.
And I ask the Entrepreneurs for the next card.
I take it, I read it out. I ask the Entrepreneurs if they want to add anything to what is written.
Then we take questions from the Dragons, and the discussion rolls.
After a while – sometimes a few minutes, sometimes a lot longer – I move to the vote, planning poker style.
I read the card out again and ask choose a card that indicates how many London Dollars this story is worth – relative to the L$10,000 card we already have.
I count down, 3, 2, 1 – show me!
And the Dragons hold up the cards. I average the answer and write the number on the story card. So, if I have a vote of 11, 21, 65 and 40 the value would be: 137/4 = L$34,000.
I usually don’t bother doing any discussion or re-voting, I just average – and I don’t care if the average is a number not on any planning poker card.
And we repeat – as a value estimate is assigned to one card we move to the next. Not every story needs to be estimated, the Entrepreneurs may decide to skip some once they see the results of previous rounds.
Entrepreneurs may write some new ones as conversations with Dragons reveals new ideas or prompts a rethink. Indeed one of the reasons I like to have more than one entrepreneur in the game is so that one can write new cards while the other is pitching and talking to the Dragons.
As each card is estimated it goes on the board with the others relative to the value assigned so everyone can see how the stories stack up.
People can really get into their role play, you can see some entrepreneurs really fighting for their product as the Dragons poke holes in the idea.
Sometimes – perhaps even most time – the conversations that occur as the game plays out are the most interesting bit. New features and functionality are brought to light. Sometimes the value the entrepreneurs see is not what the dragons see. Sometimes critical pieces of requirement or specification are discovered.
During the summer I played this game with a class in Louisiana, the entrepreneurs had created a set of stories around a food-truck locator app. Some of the stories related to the food-truck owner and some to a Hungry Jo. The entrepreneurs saw the value being on the food-truck owner side, so they emphasized this in their pitch and kept offering up stories abut the owner.
The dragons kept low-balling these stories, the entrepreneurs got frustrated and argued more, how the dragons didn’t realise what they saw.
At my promoting the entrepreneurs offered up a story about the Hungry Jo. To their surprise the dragons went high. This was the story the dragons saw value in.
Now you could say that it would be better to test the market – research or lean start-up – and I wouldn’t disagree but even if you do that it can be hard to put value behind stories. Plus, faced with 20 stories which one should you research or try first?
This approach applies wisdom of crowds. It gives you a starting point.
And as I just said, its just possible that the real value of the technique is not in the value it assigns to the cards – although that is useful – but in the conversation you have in the process.
Sure you end up with a fantasy valuation but you do have an idea of relative values, you do let stakeholders have their say, and you have some initial priorities. Much better than Must, Should, Could, etc. Potentially even better than 1, 2, 3, …
Maybe, just maybe, one day you might be able to see the value one story actually delivered – a jump in eyeballs, sales, donations or something. And with that you might be able to calculate what L$1 is worth.
Two final points before I end.
I try to keep effort estimates out of this. It is my (unproven) belief that if the dragons know the effort estimate on a card this will anchor their value estimate. I want value estimates to be made without reference to cost.
Second, a twist on this would be to revisit the story cards with a cost of delay dimension. So: value estimate the cards on the basis of “If you had this next month” then revisit then say “Now lets assume the cards aren’t ready for three months” and revote.
I haven’t had a chance to do that yet but I think it would be interesting.
Finally: if you get a chance to try this technique – or if you have done something similar already – please share, I’d love to heard what other people think of the technique and how it plays out elsewhere.
Estimating business value: adding Value poker and Dragons Den to the Agile toolkit Read More »
I get fed up hearing other Agile evangelists champion The Scientific Method, I don’t disagree with them, I use it myself but I think they are sometimes guilty of overlooking how the scientific method is actually practiced by scientists and researchers. Too often the scientific approach is made to sound simple, it isn’t.
First lets define the scientific method. Perhaps rather than call it “scientific method” it is better called “experimentation.” What the Agile Evangelists of my experience are often advocating is running an experiment – perhaps several experiments in parallel but more likely in sequence. The steps are something like this:
I agree with all of this, I think its great, but…
Lets leave aside problems of measurement, problems of formulating the hypothesis, problems of making changes and propagation problems (i.e. the time it takes for changes to work though the system). These are not minor problems and they do make me wonder about applying the scientific method in the messy world of software and business but lets leave them to one side for the moment.
Lets also leave aside the so-called Hawthorne Effect – the tendency for people to change and improve their behaviour because know they are in an experiment. Although the original Hawthorne experiments were shown to be flawed some time ago the effect might still be real. And the flaws found in the Hawthorne experiments should remind us that there may be other factors at work which we have not considered.
Even with all these caveats I’m still prepared to accept an experimental approach to work has value. Sometimes the only way to know whether A or B is the best answer is to actually do A and do B and compare the results.
But, this is where my objections start…. There are two important elements missing from the way Agile Evangelists talk about the scientific method. When real scientists – and I include social-scientists here – do an experiment there is more to the scientific method than the experiment and so there should be in work too.
#1: Literature review – standing on the shoulders of others
Before any experiment is planned scientists start by reviewing what has gone before. They go to the library, sometimes books but journals are probably more up to date and often benefit from stricter peer review. They read what others have found, they read what others have done before, the experiments and theories devised to explain the results.
True your business, your environment, your team are all unique and what other teams find might not apply to you. And true you might be able to find flaws in their research and their experiments. But that does not mean you should automatically discount what has gone before.
If other teams have found consistent results with an approach then it is possible yours will too. The more examples of something working the more likely it will work for you. Why run an experiment if others have already found the result?
Now I’m happy to agree that the state of research on software development is pitiful. Many of those who should be helping the industry here, “Computer Science” and “Software Engineering” departments in Universities don’t produce what the industry needs. (Ian Sommerville’s recent critique on this subject is well worth reading “The (ir)relevance of academic software engineering research”). But there is research out there. Some from University departments and some from industry.
Plus there is a lot of research that is relevant but is outside the computing and software departments. For example I have dug up a lot of relevant research in business literature, and specifically on time estimation in psychology journals (see my Notes on Estimation and Retrospective Estimation and More notes on Estimation Research.)
As people used to dealing with binary software people might demand a simple “Yes this works” or “No it doesn’t” and those suffering from physics envy may demand rigorous experimental research but little of the research of this type exists in software engineering. Much of software engineering is closer to psychology, you can’t conduct the experiments that would give these answers. You have to use statistics and other techniques and look at probabilities. (Notice I’ve separated computer science from software engineering here. Much of computer science theory (e.g. sort algorithm efficiency, P and NP problems, etc.) can stand up with physics theory but does not address many of the problems practicing software engineers face.)
#2: Clean up the lab
I’m sure most of my readers did some science at school. Think back to those experiments, particularly the chemistry experiments. Part of the preparation was to check the equipment, clean any that might be contaminated with the remains of the last experiment, ensure the workspace was clear and so on.
I’m one of those people who doesn’t (usually) start cooking until they have tidies the kitchen. I need space to chop vegetables, I need to be able to see what I’m doing and I don’t want messy plates getting in the way. There is a word for this: Mise en place, its a French expression which according to Wikipedia means:
“is a French phrase which means “putting in place”, as in set up. It is used in professional kitchens to refer to organizing and arranging the ingredients (e.g., cuts of meat, relishes, sauces, par-cooked items, spices, freshly chopped vegetables, and other components) that a cook will require for the menu items that are expected to be prepared during a shift.”
(Many thanks to Ed Sykes for telling me a great term.)
And when you are done with the chemistry experiment, or cooking, you need to tidy up. Experiments need to include set-up and clean-up time. If you leave the lab a mess after every experiment you will make it more difficult for yourself and others next time.
I see the same thing when I visit software companies. There is no point in doing experiments if the work environment is a mess – both physically and metaphorically. And if people leave a mess around when they have finished their work then things will only get harder over time. There are many experiments you simply can’t run until you have done the correct preparation.
An awful lot of the initial advice I give to companies is simply about cleaning up the work environment and getting them into a state where they can do experiments. Much of that is informed by reference to past literature and experiments. For example:
You get the idea?
Simply tidying up the work environment and putting a basic process in place, one based on past experience, one which better matches the way work actually happens can alone bring a lot of benefit to organizations. Some organizations don’t need to get into experiments, they just need to tidy up.
And, perhaps unfortunately, that is where is stops for some teams. Simply doing the basics better, simply tidying up, removes a lot of the problems they had. It might be a shame that these teams don’t go further, try more but that might be good enough for them.
Imagine a restaurant that is just breaking even, the food is poor, customers sometimes refuse to pay, the service shoddy so tips are small, staff don’t stay long which makes the whole problem worse, a vicious circle develops. In an effort to cut costs managers keep staffing low so food arrives late and cold.
Finally one of the customers is poisoned and the local health inspector comes in. The restaurant has to do something. They were staggering on with the old ways until now but a crisis means something must be done.
They clean the kitchen, they buy some new equipment, they let the chef buy the ingredients he wants rather than the cheapest, they rewrite the menu to simplify their offering. They don’t have to do much and suddenly the customers are happier: the food is warmer and better, the staff are happier, a virtuous circle replaces a vicious circle.
How far the restaurant owners want to push this is up to them. If they want a Michelin star they will go a long way, but if this is the local greasy spoon cafe what is the point? – It is their decision.
They don’t need experiments, they only need the opening of the scientific method, the bit that is too often overlooked. Some might call it “Brilliant Basics” but you don’t need to be brilliant, just “Good Basics.” (Remember my In Search of Mediocracy post?).
I think the scientific method is sometimes, rightly or wrongly, used as a backdoor in an attempt to introduce change. To lower resistance and get individuals and teams to try something new: “Lets try X for a month and then decide if it works.” Thats can be a legitimate approach. But dressing it up in the language of science feels dishonest.
Lets have less talk about “The Scientific Method” and more talk about “Tidying up the Kitchen” – or is it better in French? Mise en place…. come to think of it, don’t the Lean community have Japanese word for this? Pika pika.
What we forget about the Scientific Method Read More »
New year is traditionally the time of predictions, and several of the blogs I read have been engaging in predictions (e.g. Ian Sommerville “Software Engineerng looking forward 20 years.”). This is not a tradition I usually engage in myself but for once I’d like to make one. (I’ll get back to software economics next time, I need to make some conclusions.)
Actually, this is not a new prediction, it is a prediction I’ve been making verbally for a couple of years but I’ve never put it on the record so here goes:
By 2022 it will be not be possible to get a professional programming job if you do not practice TDD routinely.
I started making this prediction a couple of years ago when I said: “In ten years time”, sometimes when I’ve repeated the prediction I’ve stuck to 10-years, other times I’ve compensated and said 9-years or 8-years. I might be out slightly – if anything I think it will happen sooner rather than later, 2022 might be conservative.
By TDD I mean Test Driven Development – also called Test First (or Design Driven) Development. This might be Classic/Chicago-TDD, London-School-TDD or Dan North style Behaviour Driven Development. Broadly speaking the same skills and similar tools are involved although there are significant differences, i.e. if you don’t have the ability to do TDD you can’t do BDD, but there is more to BDD than to TDD.
The characteristics I am concerned with are:
This probably means refactoring, although as I’ve heard Jason Gorman point out: interest in refactoring training is far less than that in TDD training.
I’d like to think that TDD as standard – especially London School – also implies more delayed design decisions but I’m not sure this will follow through. In part that is because there is a cadre of “designers” (senior developers, older developers, often with the title “architect”) who are happy to talk, and possibly do, “design” but would not denigrate themselves to write code. Until we fix our career model big up front design is here to stay. (Another blog entry I must write one day…)
I’m not making any predictions about the quality of the TDD undertaken. Like programming in general I expect the best will be truly excellent, while the bulk will be at best mediocre.
What I am claiming is:
And I believe, in general, software will be better (fewer bugs, more maintainable) as a result of these changes, and as a result programmer productivity will be generally higher (even if they write less code they will have fewer bugs to fix.)
Why do I feel confident in making this prediction?
Exactly because of those last points: with any form of TDD in place the number of code bugs is reduced, maintainability is enhanced and productivity is increased. These are benefits both programmers and businesses want.
The timescale I suggest is purely intuition, this might happen before 2022 or it might happen after. I’m one of the worst people to ask because of my work I overwhelmingly see companies that don’t do this but would benefit from doing it – and if they listen to the advice they are paying me for they start doing it.
However I believe we are rapidly approaching “the tipping point”. Once TDD as standard reaches a certain critical mass it will become the norm, even those companies that don’t actively choose to do it will find that their programmers start doing it as simple professionalism.
A more interesting question to ask is: What does this mean? What are the implications?
Right now I think the industry is undergoing a major skills overhaul as all the programmers out there who don’t know how to do TDD learn how to do it. As TDD is a testable skill it is very easy to tell who has done it/can do it, and who just decided to “sex up” their CV/Resume. (This is unlike Agile in general where it is very difficult to tell who actually understand it and who has just read a book or two.)
In the next few years I think there will be plenty of work for those offering TDD training and coaching – I regularly get enquiries about C++ TDD, less so about other languages but TDD and TDD training is more widespread there. The work won’t dry up but it will change from being “Introduction to TDD” to “Improving TDD” and “Advanced TDD” style courses.
A bigger hit is going to be on Universities and other Colleges which claim to teach programming. Almost all the recent graduates I meet have not been taught TDD at all. If TDD has even been mentioned then they are ahead of the game. I do meet a few who have been taught to programme this way but they are few and far between.
Simply: if Colleges don’t teach TDD as part of programming courses their graduates aren’t going to employable, that will make the colleges less attractive to good students.
Unfortunately I also predict that it won’t be until colleges see their students can’t get jobs that colleges sit up and take notice.
If you are a potential student looking to study Computer Science/Software Engineering at College I recommend you ignore any college that does not teach programming with TDD.
If you are a college looking to produce employable programmers from your IT course I recommend you embrace TDD as fast as possible – it will give you an advantage in recruiting students now, and give your students an advantage finding work.
(If you are a University or College that claims to run an “Agile” module then make sure teach TDD – yes, I’m thinking of one in particular, its kind of embarrassing, Ric.)
And if you are a University which still believes that your Computer Science students don’t really need to programme – because they are scientists, logisticians, mathematicians and shouldn’t be programming at all then make sure you write this in big red letters on your prospectus.
In business simply doing TDD, especially done well, will over time fix a lot of the day-to-day issues software companies and corporate IT have, the supply side will be improved. However unless companies address the supply side they won’t actually see much of this benefit, if anything things will get worse (read my software demand curve analysis or wait for the next posts on software economics.)
Finally, debuggers are going to be less important, good use of TDD removes most of the need for a debugger (thats where the time comes from), which means IDEs will be less important, which means the developers tool market is going to change.
(Postscript: sorry about the formatting problems with the first upload.)
Programmers without TDD will be unemployable by 2022 (a prediction) Read More »
