Lean: Results are not the Point
Published March 3rd, 2010 Under Quotes | Leave a Comment
I have just finished reading the great book “Leading Lean Software Development” by Mary and Tom Poppendieck and I wanted to share with you two quotes excerpted from it.
[...] I started a conversation with the question that had been bothering me: “How do you reconcile the lean view that tests are waste with the need for tests in software development?” Mary’s immediate response: “Unit tests are what let you stop the line.” (quoted from the Foreword by Dottie Acton)
In our experience, the most common causes of policy-driven waste in software development are:
1. Complexity
2. Economies of scale
3. Separating decision making from work
4. Wishful thinking
5. Technical debt
The strategy of designing the effort to fit the constraints, rather than computing the constraints form the design, is absolutely the most effective way to achieve reliable delivery.
Reference: “Leading Lean Software Development – Results are not the Point”, Mary and Tom Poppendieck, Addison-Wesley, 278 pages, IBSN 978-0-321-62070-5
It could seem very provocative to propose an approach based on the slogan ” Results are not the Point”. In their book, the Poppendieck defend the idea that there are many good managers around that could foster the adoption of lean practices. From my personal experience, most of the managers thinking “results are not the point” do this because they think “costs are the most important point”. This is why I think that companies that adopt agile or lean approaches want results…. and quickly! We could all wish that more managers and developers take the time to read book like this one, but even if it was the case, I am very dubious that many companies will really abandon their “command and control” and “short term vision” culture.
Get more details on this book or buy it on amazon.com
Get more details on this book or buy it on amazon.co.uk
How Do You Refactor Untested Code?
Published February 9th, 2010 Under Quotes | 3 Comments
I am currently reading the excellent “Debug It!” book written by Paul Butcher and I wanted to share with you some of the little gems that I have found in it.
“Bug fixing often uncovers opportunities for refactoring. The very fact that you’re working with code that contains a bug indicates that there is a chance that it could be clearer or better structured.”
“As a rule of thumb, for every user who tells you about a problem, there will be between 10 and 100 other users who experienced the same problem and didn’t think to get in touch.”
“Once you start to get on top of your quality issues, you’re going to want to start refactoring the old, crufty, untested code. And you should – the point of exercise is to clean up problems, and refactoring is a key element of that process. Remember, however, that refactoring crucially depends upon the support of an extensive suite of automated tests. Without tests, you’re not refactoring. You’re hacking. So, how do you refactor untested code? You don’t. The first thing you do is to write the tests.”
Source: “Debug It!”, Paul Butcher, Pragmatic Bookshelf, 214 pages
Changing Perspectives
Published January 26th, 2010 Under Quotes | Leave a Comment
“In the early days of our industry, programmers wrote in assembly code, selecting registers in which to place variables and managing memory explicitly. If we had magically provided these programmers with a Smalltalk compiler, they might have asked, “How does this help us select registers? How do we allocate memory?” They might have concluded, “”We don’t want no stinkin’ Smalltalk!”
Old and new programmers are still writing programs, but the technology to achieve the goal has changed. When a new technology is sufficiently different, you can’t evaluate it in terms of the old technology.”
Source: Stephen J. Mellor, Letters section, IEEE Software, March/April 2004
Sometimes new ways of doing things come in our life and it might be difficult to adapt. If you are used to drive a car and you take a train, you don’t ask how you are going to “turn left”: the train just follows the tracks. However, you have now to go to a station, buy a ticket, look at timetable, etc… This could be the same thing with some of the software development approaches that have recently become popular.
Functional programming, domain driven design or frameworks that favors convention over configuration like Ruby on Rails can offer a new perspective about what you have to do to develop software. If you have the time (and the energy) I would like to strongly encourage you inform you about these approaches or even better to try them. Ironically, the above quotation was in reply of a letter about UML and Model Driven Architecture. Six years after, there is not a lot of people still caring about this way of developing software, as it is for Smalltalk or assembly languages.
Resources
* Wikipedia.
* Articles
Functional programming – HaskellWiki
Functional Programming For The Rest of Us
An Introduction to Web Development Using the Ruby on Rails Framework
An Introduction To Domain-Driven Design
An Introduction to Domain Driven Design
You Are the Raw Material of Software Development. Are You Good Enough?
Published January 6th, 2010 Under Quotes | 1 Comment
The end of the year is a time where you do some cleaning. During this activity, I found an old issue of IEEE Software where I had noticed an article as a source of interesting software development quotes about people issue. As New Year is also the time to take good resolutions, this should help us to deal with average people that we mostly are… and with the below average developers that normally will not read this ;o)
“Any construction project begins with raw material, and as Confucius suggests, the nature of the raw material is critical to success – so much that you shouldn’t even begin if the “wood” is poor. Even if you have sharp, finely honed tools, your project will still fail if the raw material isn’t sound. And what, might you ask, is the raw material of software development? Us. People. We are the only raw material of consequences in software development.
[....] So how do we prepare this material? Obviously, we don’t want it to be “rotten”, but how can we tell? How can we tell if hidden voids lurk beneath the surface, just waiting to ruin the project once we start carving? When you lack the right material, you’ll keenly feel its absence. For example, warning signs might include:
* The developer who only uses one favorite solution for every problem
* Folks who don’t learn from mistakes – or worse, are too afraid to make any
* The developer who can’t be bothered to tell anyone what he’s doing and why
[...] Painful as it is to admit it, for most people, most of the time, the problems that come up are our own fault – not the compiler’s, not the OS’s, not the database vendor’s, not our bosses’, and not our coworkers’. Yet many people and team, when facing a disastrous problem, first embark on a search (aka witch-hunt) to fix the blame. It goes somewhat against human nature, but you should always try to fix the problem, not the blame. Remember we all write software in our heads, so it makes sense to go ahead and take responsibility for it. “The cat ate my source code” just doesn’t cut it anymore – when problem come up, we need to invent options, not excuses.
[...] The isolated, lone developer huddled over a terminal with a can of highly caffeinated cola offers not only an inaccurate and misleading stereotype, but a dangerous one as well. Isolated developers can inadvertently duplicate other teammates’ work, use outdated or inappropriate methods, and even build the wrong product – at least, not the product the sponsor wanted. Instead of taking more Java and UML courses, we should work on our technical writing, public speaking, and group facilitation. A CPU with no I/O isn’t very useful. Neither is a developer who can’t communicate.”
Source: Andy Hunt and Dave Thomas, “Preparing the Raw Material”, IEEE Software, September/October 2003
My only disagreement with the authors is that I think that the end users are also essential raw material in software development, but I fully agree with the idea that we should take responsibility for our own limits. Fresh out of the University, one of the first important modification that I did created a big trouble, because I didn’t tested it with the right files, even if my supervisor suggested this to me ;o( This taught me that being confident with my work could be good… but thoroughly testing it was even better ,o)
Agile Project Management Insights
Published December 16th, 2009 Under Quotes | 1 Comment
I am currently reading the book “Agile Project Management” from Jim Highsmith. I will publish a review later on this blog, but in the meantime I would like to share some of the interesting quotes that I have found in the book. I am sure they will make sense to software project managers… and developers ;o)
About adding value
“When Ward asked Toyota’s American engineering and managers how much time they spend adding value (i.e., actually doing engineering work), their response averages 80%. The same question asked of engineers and managers at American automobile companies averages 20%. How can you compete with companies that are getting four times as much value-adding work from their development engineers.” (referenced from “Product Development for the Lean Enterprise”, Michael Kennedy, the Oaklea Press, 2003)
About technical knowledge
“As a software development consultant, I’ve never encountered a successful software company (although my sample size is limited) in which the team and project leaders were not technically savvy. [...] Championing technical excellence requires that the project leader, and team members in general, understand what technical excellence means – in the product, the technology, and in the skills of the people doing the work.”
About leading or managing
“Agile leaders lead teams, non-agile ones manage tasks. How many project managers spend hours detailing tasks into Microsoft Project and then spend more hours ticking off task completions? Unfortunately, many project managers like this task oriented-approach because it is concrete, definable, and completion seems finite. Leading teams, on the other hand, seems fuzzy, messy, un-definable, and never complete. So naturally some people gravitate to the easier – managing tasks.”
About self-organization and anarchy
“Self-organizing teams are at the core of the agile management, but the concepts have become corrupted – and counterproductive – in parts of the agile community. Although self-organizing is a good term, it has, unfortunately, contingent within the agile community who encourage an anarchistic management style and have latched onto the term self-organizing because it sounds better than anarchy. As larger and larger organizations are implementing agile methods and practices, the core of what it means to be agile – an empowering organizational culture – may be lost because large organizations will reject the cultural piece of agile.”
About the value of a plan
“When we “plan”, we expect the actual project result to conform to that plan, and then deviations become team mistakes or sign of the team’s failure to work enough. When we “speculate”, we take the opposite perspective – it’s the plan we suspect was wrong. The plan, or speculation, is a piece of information, but it is only one piece that we will examine to determine our course of action in the next iteration.”
About software malleability
“Software is the most malleable product. Companies need to use this characteristics to their competitive advantage, and sticking to traditional waterfall development negates this advantage.”
Reference: “Agile Project Management”, Jim Highsmith, Addison-Wesley, Second Edition
« go back — keep looking »