Wegner’s Lemma and System Proposals (Agility vs. Ridgity)
I do not have an extensive background in science. My soon wife does. She will have her PhD soon. In researching Scrum and Software Project Management, I ran into this thing called “Wegner’s lemma” and I asked her what a Lemma was. She asked if it wasnt one of those monkey-type animals. I told her she was thinking of a lemur, and realized that this is probably not science and should stop bothering her with more philosophy and theory that isnt about nanoparticles.
From what I can tell, a lemma is somthing that is assumed to be true so we can move forward under a given premise.
From Jeff Sutherland:
Wegner’s lemma - an interactive system can never be fully specified nor can it ever be fully tested. This is the software analogy to Godel’s theorem.
And now I have to mention Godel’s theorem. A theorem is a bit stronger than a Lemma. It has been banged on my scientists and other smart people, accepted as true or at least, having merit.
What’s with the fear of commitment? I guess you cannot apply Scrum principles to mathematics or logic. I am a big fan of logic (Ayer, especially), and so I understand. What I dig about Ayer is his principle of nonsense. I am sure if my old Professors heard me call it that they would choke on their oatmeal, but Ayer says that any statement that cannot be proven true or false is nonsensical, and that every statement that can be proven true is a tautology. Makes good, tight, sense to me.
This is not wholly irrelevant to software engineering. Bear with me.
I am going to cop out a little here, because it give me a headache, but you can read about Godel’s theorem here. It has been extended into many different verticals, disciplines, and websites. It seems to be just short of a Law. If it interests you to understand it’s complexities, please pursue the aforementioned link. You will find many other links there.
Below, you can read about how all this applies to your approach at scoping a software System and creating a proposal.
Lots of clients want a firm proposal with a firm, fixed price. They probably have experience with manufacturing processes, and so the Waterfall approach makes sense to them. This understandable. Software Engineering (new development), however, is not manufactuing. Unless you are prepared to eat potentially copious personhours of labor or fall short of customer expectations, you need to build a little slack into your proposal. This is classically done by using a multiplier, or by pricing iterations. Always seemed a little sneaky to me. The line item “Slack” reads like a copout.
Wegner’s lemma speaka to the validity of an iterative process of discover, code, deliver; indeed, it was one of the arguments used to support and ititiate the pursuit of Scrum before Scrum had been proven. Scrum is not new, contrary to popular belief. I mentioned in a previous post that we had something very similar to scrum at my family’s construction business, but it has been a software process for over ten years. It is finally getting real traction. If it did not work, you would not still be hearing about it. That’s the good thing about theories, I guess; if a theory proves to be bologna, you stop hearing about it pretty quickly.
You have three ways to approach a software proposal, if not more:
Give transparency into your process, deliver frequently, and this is pallatable. “Tust me” rarely works in the absence of a bullet-poof reputation of long-standing relationship.
There are really two options: commit to a Contract or commit to a Contracted System. A contract is not flexible and does not benefit anyone when it asks them to commit to ambiguity. A System is much more robust.
Here, we invoke Wegner’s lemma and our experience building software. Again, the requirements wind up being the source code.
Of course, I think the best is a combination approach. Do some initial requirements so you are not playing code cowboy. Then, engage the client in an iterative approach, grounded in a proven iterative methodology (like Scrum or XP or MSF) and keep communication open. If your client is able to see progress, they will not see your function as a black box. And if you make them the Product Owner, allow them to prioitize features (user stories), they will not have to ask why they do not have feature X yet. They will have asked for features D and E and delayed feature X in a calculated decision.
PS: As an asid, I’d like to mention, I am not really digging this new version of WordPress under FireFox. It is slow as anything. Under Opera, it seems a lot better.
Update 061108
Craig Brown is one of my favorite readers. He always has interesting comments (or he did, when I allowed comments… and there are 2 reasons I don’t anymore) and I wind up reading his blog and learning something when he engages me. That’s right Craig, you engaged me.
I want to respond to Craig directly because he is a smart guy that I respect although for all I know he has a suit made of human skin. I am not suggesting that people start contracting a system as much as I am suggesting that part of the client engagement include education and that *our* discipline stops being so defensive and starts getting down and dirty with the critics. I want real metrics. I want a marketing machine. I want what is best for humankind. I am a very sweet guy.
I have not seen software engineering really face, head-on, the world of clients who expect the more traditional manufacturing model. In contracting a system, I am suggesting that clients understand what they are contracting (in an Agile model) and I do think it is any more similar to “time and materials” than hiring any specialist is. Take a large investment firm. Go to them as a small software company and ask they to just trust you because you will be giving them frequent updates.
My doctor gave me frequent updates during my colonoscopy.
I invoke Wegner’s lemma and neglect to get into it deliberately. I maintain that project management and indeed software engineering as a whole are less science than art. Sure, we have color theory, but when it comes down to it, either you got it or you don’t (ability). We need more talented, open-minded, caring people who want to produce to the best of their abilities and not just slap “PMP” on the resume because it gets you a 20 percent higher salary and financial institutions wont talk to you without it. This will change SOON. Mark my words. We are going to see a hybrid of hybrid models. We are going to become trailblazers instead of pencil pushers.
BTW - I am not a pencil pusher. No Sir-ee Bob.
This applies to PMs, BAs, and software engineering firms. I do not understand Wegner’s lemma, but it has been fodder for the Agile community and I would like to see that stop. We do not need more pseudo-science or forced analogies, any more *almost* universal techniques, excuses, or approaches. We need to be honest and upfront and tell it like it is.
I invoke something I do not find palatable because I have a degree in philosophy, and it taught me one thing; you can talk theory all day, but at the end of the day, it is mental masturbation (excuse me) until you can actualize, materialize, and deliver something tangible. Tangible may take the shape of an idea. It may be a widget. But still, Wegner’s lemma does not manifest directly. We should not point to it for excuses.
Instead, we should progressively elaborate (sorry PMI) as a community and make change. Agilists become frustrated when you ask them “When and how much?” and I think it is a shame. We can give answers. We just cannot commit to a specific figure unless we
- are prepared to lose money
- pad our estimates heavily
- have done it before and are just generally amazing
- define scope and really insult the customer when our scope doc, that we knew was incomplete, falls short of being complete
Thanks, Craig.
Josh
