by Prof Barry Dwolatzky
In just under 6 weeks we will be running the inaugural “Agile Africa” Conference. Registrations opened today (details here) and social media started buzzing with questions and comments. Why no African keynote speakers? Why no women? Why so expensive? While all of these comments are important and valid (and deserve a response), I got to thinking about something quite different – How did the great annual conferences in the world get started? Continue reading
Martin Fowler – one of the Agile Africa 2013 keynotes
I’ve been rolling up my sleeves to help get the “Agile Africa 2013″ Conference going. “Agile India”, “Agile South America” and others have all appeared on the international conference landscape, so why not an “Agile Africa”.
The idea was first explored in 2012. Unfortunately the people driving the idea didn’t manage to pull it off. The JCSE, in partnership with the company “ThoughtWorks”, and a group of interested Agile practitioners decided to make it happen in 2013.
We now have a date – 12 & 13 August, a venue – the Alex Theater in Braamfontein, and a great list of keynote speakers – Martin Fowler, Ivar Jacobson, David Hussman, Mitch Lacey, Amr Noaman.
We are now going live with a call for sponsors and registrations. For more details contact me (until we have our official website). I’m at barry@jcse.org.za .
by Prof Barry Dwolatzky
Software Methods are like a fashion show
Software Engineer #1: What methodology are you using these days?
Software Engineer #2: We’re into Lean in a big way …. with a few XP practices thrown into the mix. We were very into Scrum last year, but then I read this amazing book and really got hooked on Lean.
SE #1: I remember the arguments we used to have a few years ago. You tried to convince me that Agile was a recipe for disaster. I think you were very keen on RUP at the time.
SE #2: That’s right. I was very young and immature then. I’ve got a much deeper understanding now of how software development really works, and I have absolutely no doubt that Lean and Kanban have all the answers for me.
by Prof Barry Dwolatzky
You’re reversing your car when, suddenly, you hear a loud crunch as you drive over something. You stop, jump out and run to see what you’ve hit. It’s your 5-year-old daughter’s tricycle crushed under your back wheel. Someone must have left it in the driveway yesterday. What do you do next?
by Prof Barry Dwolatzky
I’ve just received the really sad news that Watts Humphrey died today (Thursday 28th October) aged 83 years old.
Watts Humphrey was one of the world’s most influential figures in the field of software engineering. In 1986, after retiring as the head of software at IBM, Humphrey joined the Software Engineering Institute (SEI) at Carnegie Mellon University in Pittsburgh USA. For the next 24 years he drove the development of the Capability Maturity Model (CMM), the Personal Software Process (PSP) and the Team Software Process (TSP). His work brought the concepts of process, measurement and continuing improvement to the software development industry.
Watts Humphrey’s death came a few days after I unveiled my ambitious strategy to create 1,000’s of new jobs in the South African software sector. This strategy is largely based on Humphrey’s contributions to software engineering. The strategy began to take shape when I first met Watts in Mexico City in 2008, where I was leading a delegation from South Africa investigating TSP adoption. He was keenly interested in the South African software sector and its future prospects.
Anyone who met Watts Humphrey could not fail to be inspired by his clear vision and boundless energy. His books are wonderful to read – they’re filled with the wisdom of his decades of experience and lots of common sense.
I will always be inspired by Watts Humphrey. I remain determined to build, here in South Africa, on his wonderful work. I see his work as a tool and inspiration that will change the lives of those in our country who develop and use software.
by Prof Barry Dwolatzky
A certain company in Johannesburg has, over the past few years, been outsourcing its software testing to a large Indian company. The value of this contract is R400 million per annum. The Johannesburg company employs several hundred software developers who write applications that support its business operations. It is these applications that are tested in India.
The major aim of software testing is to expose “defects”. These defects are errors made by analysts, architects, designers and programmers during the software development lifecycle. Various international studies suggest that a piece of software going into system test contains more than 25 defects per thousand-lines-of-code [KLOC]. Data collected by Xerox in the USA concluded that the average time required to remove each defect found in system testing is 1405 minutes (or 23.4 hours). This time includes the time required to find the symptoms of the defect in testing … and then the re-work to be done by the original developer in locating and fixing the error.
Defects are therefore costing the Johannesburg company mentioned above much more than the cost of the R400 million outsourced testing contract. There is also the large amount of wasted time spent by their in-house developers on re-work and debugging. At 25 defects/KLOC the company is shipping many thousands of defects to India. Some of these (but certainly not all) are then reported back to Johannesburg where tens of programmer-hours are required to fix each one.
The waste in effort and money is almost mindboggling!! Surely there is a better way?
I believe that the answer lies in putting higher quality code into system testing. It is obvious that if a way could be found to reduce the number of defects per KLOC from 25 to (say) 10 the saving would be tremendous. Not only that – we would also make software development projects more predictable.
The reason for this is that the time it takes to find and fix a defect is very unpredictable. Simple defects are found and cleared in minutes. Others may take days or even weeks to resolve. It is therefore obvious that the fewer defects found in testing the more predictable software development projects would become.
Another key issue about finding defects in system test is that because it is extremely time-consuming and unpredictable the project usually runs out of time and budget before all defects are found. The development team knows that if more tests are run more defects will be found … but who will pay for this extra testing effort?
There is a proven way of dramatically reducing the number of defects in software before system testing starts. It lies at the heart of the “Team Software Process” (TSP) that is now being used with great success by companies in the USA, Mexico and elsewhere. We at the JCSE have just run a year long TSP pilot at Nedbank. The results in terms of quality have been extremely encouraging.
On Tuesday I will be unveiling the JCSE’s “Thousand Job Strategy” which aims to make a significant impact on the South African software development sector. TSP as a way of improving the quality and predictability of software development projects is a central element of the strategy.
If you are interested in hearing more and debating this strategy with me, please join us at the JCSE’s Annual Process Improvement Symposium on the morning of Tuesday 26th October 2010 (see www.jcse.org.za for more details). If you can’t join us then hopefully the debate will continue on this blog where I will post more details of the strategy after its launch on Tuesday.