The One Thing You Need to Know … About Software Development
Correctness can be confirmed at any time is the subtitle of Mary’s talk and it start off with the clear statement that Waterfall does simply not work. So let’s hear what works :-).
The question is how to deal with complexity and the answer to some extend is divide and conquer. Mary continues with some history on how to archieve this. Basically everything has been “structured” back in the 70s, which does also not really solve the problem as we know today. But what we really want is not to inject defects already from the very beginning. An early answer to this was given by Edsger Disjkstra which basically was a form of layered architecture.
After the long discussion about architecture with Tom Gilb yesterday night in the hotel lobby my fingers are not too calm while writing about architecture here 😉 … but back to Mary. The question is how has the software to work on various levels? E.g. unit level testing and business level testing.
Next in the history is Harlan Mills with his Top-Down Programming approach, which should help avoiding any difficult integration. It’s a kind of step-wise integration, which could be seen as an early version of continuous integration what we discussing today in agile. So as with the discussion wth Tom yesterday it seems that quite some agile ideas are not really that new.
Next in history is Dave Parnas and his “Criteria of Decomposition”. This immedietly reminds me that Tom was saying that too many archtecture are doing nothing but decomposition and this is not architecture, but this is again another story. The idea was to divide the program to ease future changes … so this comes close to the idea Uwe is promoting, which is “Architecture for Maintenance”. And sorry I have to admit here I was too slow to keep up with the hstorical view, but we will catch up. (At this point Andreas and me are pairing on this blog entry, very cool.)
1976 it is analysed that the main problem in software development is maintenance costs (again) and the solution to this problem is to find defects early! For this shorter development cycles are needed than in the known Waterfall process.
1981 Tom Gilb is hitting the scene with the concept of starting with a short summary of the measurable business goals of the system. Those must be unambigious, testable and must not contain design. Hmm, sounds very familiar as it is basically the core statement of his lecture yesterday. It is always very nice to get these kind of “cross connections”. So we are back at:
“Prevent defects injection in the first place!”
How to learn how to avoid defect injection? Right, let’s think of a “Defect Injection Process”. It starts with a Specification and one team writing the code and another team writing the Tests. Sorry, this does not match at the end and we have a defect injection process. Next idea: Combine writing the tests together with the specification and then write the code to implement the expactations imposed by the tests.
Back to “Conquering Complexity” and the question how to deal with complexity and the answer is divide by reposibilities and value. This evolves to the three rules of lean development:
- Design matters
- Correctness can be confirmed at any time
- Failure is a learning opportunity
Mary continues with some quite high-level examples how to develop a system. Of course she is making “bonus points” by referring to the “iPhone” as a good example for such a good design of an overall system.
Now it gets more concrete again with the question how much time of the release cycle is used for finding and removing bugs (system hardening)? The answer is that top companies are only using less than 10% for this while sometimes even 50% of the time in a release cylcle is used for this. But it cannot be the aim to use that much of your valuable development time for this, so find defects earlier in the process. And with this Mary comes back to the topic that you can confirm correctness of your software at any time and not only at the end of your release cycle.
“No correlation between size of the code base and bug rate: Complexity handled completely.” (from an example developing an embedded system)
Now we come to Agile: We have short and stable iterations. And the stakeholder can give and gets feedback every iteration. And this would not be called “Agile Testing Days” without a good example how automated tests have let to a very successfully project when IBM was introducing agile. Sounds like continuous integration and early automated testing, even without FitNesse and Robot.
“People do not want software, they want something else.”
Basically people want their top objectives implemented and thus problems solved. Mary is also promoting TDD to archieve this.
“The biggest defect is tolerating defects.”
And Mary is emphasizing that you must learn from failures as it indicates a lack of understanding. This is always an opportunity to learn. Anyway, in a very diciplined program only a few defects will escape.
Ok, as we are talking about lean here there must be some example from Toyota :-). Mary describes how Toyota is coming from the current condition to their vision. For this you need to overcome one obstacle with every step to come closer to your vision.
Andreas sums this up that a lot of this was already discussed on the tutorial on Monday, but it was good to have it repeated again.
Was this post helpful?
More articles
fromThomas Jaspers
22.2.2019 Your job at codecentric?
Jobs
Agile Developer und Consultant (w/d/m)
Alle Standorte
More articles in this subject area
Discover exciting further topics and let the codecentric world inspire you.
Gemeinsam bessere Projekte umsetzen.
Wir helfen deinem Unternehmen.
Du stehst vor einer großen IT-Herausforderung? Wir sorgen für eine maßgeschneiderte Unterstützung. Informiere dich jetzt.
Hilf uns, noch besser zu werden.
Wir sind immer auf der Suche nach neuen Talenten. Auch für dich ist die passende Stelle dabei.
Blog author
Thomas Jaspers
Do you still have questions? Just send me a message.
Do you still have questions? Just send me a message.