Code Craft
The art, science and craft of writing quality software

Scientists prove uncertainty of requirements (Nov. 16, 2005)

Posted in Humor

A team of scientists at the prestigious Ritenokode University in Prague released startling new findings today that prove that the so called "software requirements" which have been a staple of high-energy coding theory for over forty years are not what we have believed them to be. While additional experimental verification is required, the findings are likely to change the way we think about software and some scientists are already hailing them as the most important discovery in coding theory since the discovery of NP completeness.

According to Dr Pike Ritchie, who led the research team, the discovery stems from a complex analysis involving measuring the speed-of-code against requirements. "For years we have believed that code moves through this theoretical space we called requirements and we would attempt to measure its speed through those requirements to compute the speed-of-code. What has always been a problem is that requirements never remain fixed, so our calculations were never accurate. While we could determine that the speed-of-code is a very small number, we could never quite pin it down because the code moved much more slowly than the background requirements against which we were attempting to measure it. These computations have been made additionally complex because we never have a pure coding space in which to measure it, instead we measure it using different forms of code, sometimes called languages."

In the experiment, Dr. Ritchie and has colleagues created created something called a fixed requirements specification. In the day-to-day world such entities never occur and have been only a theoretical construct for years, but under carefully controlled laboratory conditions the Prague-based team was able to create a fixed requirements specification and hold it in place for as long as one hundred nanoseconds (roughly 1 millionth of the time it takes you to blink your eye). Dr. Ritchie and his team had hoped to use this specification to measure the speed-of-code in various language mediums but what they found instead has rocked the software world.

"We had made the requirements as small as theoretically possible in order to maintain them as fixed; they were what we call a one bit requirement specification. We would get the requirements stable in a vacuum held in place by strong firewalls to protect them from change. As we would get the code complete, as soon as the syntax was correct the requirements would simply wink out of existence or in some cases they would change. At first, we thought this was just a coincidence, but we were able to repeat it over and over using the standard high-speed coding languages like Smalltalk, LISP and Perl but also using obscure languages like ALGOL and PL/1."

To explain this phenomenon Dr. Ritchie has proposed what he calls the requirements uncertainty principle which states that at any given time you may know the code or the requirements but never both. Opinions about the findings range amongst code-theorists. Some doubt that the findings will be verified while others feel that the conclusions about the uncertainty of requirements are still premature, but most seem to feel that the findings do represent an important new discovery. Noted codist Dr. Burt Stein has stated that he feels that while the data is probably correct the interpretation cannot possibly be, in an off-the-cuff comment he is reported to have joked that, "Management does not play dice with the company."

In the professional coding community the reaction has been much more subdued. According to Kent Bick a coder for the giant firm of Minisoft, "Well, DUH... Everyone knows that requirements never match the code. I just wonder why people think they should pay these guys for stating the obvious."

2 CommentsPost A Comment!Permanent Link


Share and enjoy
  • Digg
  • del.icio.us
  • DZone
  • Netvouz
  • NewsVine
  • Reddit
  • Slashdot
  • StumbleUpon
  • Technorati
  • YahooMyWeb

Something useful for programmers (Sep. 21, 2005)

Posted in Humor

A few people have commented to me recently that I don't write enough stuff that is useful for the average programmer; it's either abstract or written more for managers than people in the trenches.  I'm a good hearted and humble soul who always aims to please and is loved by children, dogs and old-people so I feel it's time for me to write something that will help the lowly programmer, even if she writes code in VB.  Let me start out with the following code segment.

if (u == currentCode.reader()) {
    location = diagram.after();
    u.skipTo(location);
} else {
    u = manager;
    u.stopReading(article);
}

Now, given this code, and considering the implications of the sum of the digits of its Godel number, it can be seen that relativistic interpretations of the underlying modular forms will produce unstable empiricism in non-linear hyperbolic spaces.  In systems that utilize supernatural numbering algebras these limitations can be overcome via cyclical-determinism (we shall not consider either silly or impish numbering schemes).  The following diagram should make this perfectly clear.

There, that should guarantee that any managers who stumble upon this article will not still be reading it.  I shall now share with you the secret of my amazing success as a programmer.  This is the key to the kingdom so guard it well grasshopper.

Just modify the email below appropriately and send it to your boss.  It's always worked for me!

[Manager's name] I've seen that a lot of the companies around town are really starting to implement this ridiculous metric of word-counting.  Yesterday a friend of mine in the IT department accidentally saw this in an email from [your CEOs name]. 

> The McKenzie consultant we brought in has suggested we push for a word-counting
> metric across the development organization.  They say our word-count
> numbers are very low compared to others in the industry.  Companies using word
> count have seen their numbers go up as much as 30% to 50%. This is the hot new
> measurement tool and we need to get on it.  I hate it that we're behind in this
> important area.  If someone in one of your teams is using it already put them in
> for a promotion.  If not, let's start asking the hard questions about why not.

Sure I know how to do word counts, but I want to state clearly and unequivocally that this is an unfair metric that places our organization at risk.  Not all code is the same.  Our work is more complicated than other people's work.  If you implement this people will be working late nights trying to keep up.

---[Your name]

The amazing-mind-blowing power of this plan is that now you control your company's metrics.  After your manager switches to word-counting as the basis for progress tracking, bonuses, etc you can add as much arbitrary success or failure to your apparent progress as you want.  This means you can refactor when needed and do whatever else is required to make the code better, all the while placating your manager with meaningless data.  Your workload will drop 50% and your ability to get important technical work done will go up 200% (metrics courtesy of BCG).

One of my managers hired consultants to come in and do training on word-count.  If you think they told him that word-counting is a bogus metric you would be wrong; they had two weeks of process re-engineering meetings and skill-building exercises and then we went back to business as usual but with word-count as the official new corporate standard.  It was even discussed prominently in our ISO certification.  We still see the consultants annually for about a week of process improvement meetings.

Now how's that for PRACTICAL advice?

[P.S. some of you may be worried that I may in fact be a manager.  That's ok I stopped reading before I got to the diagram.]

3 CommentsPost A Comment!Permanent Link


Share and enjoy
  • Digg
  • del.icio.us
  • DZone
  • Netvouz
  • NewsVine
  • Reddit
  • Slashdot
  • StumbleUpon
  • Technorati
  • YahooMyWeb
<- Last Page • Next Page ->

Kevin Barnes

Code Craft is the place for my thoughts, rants, ideas and occassional jokes on what it means to write code, why some people are better at it than others, and how we think about software in general.

Links

Home
View my profile
Site Feed (RSS)
Archives
Email Me
StorePerform
TechNexxus
Soul Craft (my stories and discussions)
My Wall

Joel on Software
Paul Graham
Patric Logan
Martin Fowler
Free Blogs
Free Blog



Copyright (C) 2005, Kevin Barnes. All rights reserved.

portfolio