Update & Share tips on Testing, Develoment, Design & Other New Tech Trends

Post Top Ad

Post Top Ad

Tuesday, July 25, 2017

Wegners 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 wasn't 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 isn't about nano particles.


From what I can tell, a lemma is something 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.

Godel 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 manufacturing. Unless you are prepared to eat potentially copious person hours 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 co pout.

Software engineering defition


Wagner's lemma speak to the validity of an iterative process of discover, code, deliver; indeed, it was one of the arguments used to support and initiate 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:


  • You can spec out a Big Up Front Requirements Phase and Development, QA, Implementation phases.
  • Similarly, you can spec out a Big Up Front Requirements phase that with speak to a more informed development phase, probably with iterations or a release schedule
  • you can argue Wagner's lemma and say that really, “we will not know what we are going to bump into until we bump into it, and as much as we have some historical information, your System is unique and to commit to anything besides something wholly unsatisfactory would be plain dishonest.” More formally, “your system will require an iterative approach, because when it is being developed, it will be done so within a dynamic environment that we would love you involved in so you can have transparency into the process and control over what is prioritized. Also, your system is new development, and there are many ways to approach it. We need to determine, along with you, what will work best. We are very good at building software, but equally important is our skill at building the *right* software”… or something. Give transparency into your process, deliver frequently, and this is palatable. “Rust 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.


    No comments:

    Post a Comment