Life is a bug

Vraag het Microsoft:

http://windowssecrets.com/comp/081024
A remote-code exploit that could spread rapidly like the 2003 MSBlaster worm is putting all versions of Windows at risk.

Onzekerheid is de enige constante factor in het leven.
Hoewel?
Software bevat bijna altijd bugs.
Er zijn rookvrije cafés, maar alcoholvrij is echt enige deuren te ver.

Dus er zijn wel zekerheden.
De mens is feitelijk een bug van moeder natuur.
Vraag dat maar aan Darwin. http://nl.wikipedia.org/wiki/Charles_Darwin
Zonder "foute" genmutaties is er geen evolutie.

Zonder innovatie zullen uiteindelijk de bugs uit de software verdwijnen.
Door innovatie zal software voortdurend veranderen en weer nieuwe bugs bevatten.

Zie ook: http://www.computable.nl/artikel/ict_topics/development/1291158/1277180/prof-brinksma-foutloze-software-voorlopig-nog-utopie.html
"Het bouwen van software is nog steeds een creatief ambacht. Er bestaan nog onvoldoende wetenschappelijke grondslagen om te komen tot een voorspelbaar en beheersbaar produktieproces. De software-branche bevindt zich nog in de pre-industriële fase, waarin ieder produkt volgens de specificaties van de individuele klant wordt opgeleverd."

Gedateerd (22-11-1996 00:00) en om middernacht gepost (...) maar helaas nog steeds actueel.

Maar ook een oplossing draagt hij aan:
Hij pleit dan ook voor verdere professionalisering, temeer omdat investeringen op dit gebied behoorlijk lonend kunnen zijn. Een voorbeeld: Oorlogsfabrikant Raytheon investeerde een miljoen dollar per jaar in verhoging van het niveau op de cmm-schaal en de training van vierhonderd programmeurs. De resultaten: een sprong van twee cmm-niveaus in drie jaar, een verhoging van de produktiviteit met een factor twee en een rendement van bijna 8 dollar op iedere geïnvesteerde dollar. Bovendien zijn de meeste projecten voortaan voor tijd en binnen de begroting gereed.

Jammer dat het een Oorlogsfabrikant betreft.
Wat is in ...naam een Oorlogsfabrikant?

Tja, een bug in een wapen is nooit handig.
Noem het dan maar collateral damage. http://en.wikipedia.org/wiki/Collateral_damage

Ook leuk in dit verband:
http://www.yuwantitwhen.com/blog/2007/10/22/part-1-how-to-manage-an-unrealistic-schedule/
This is when many mangers make the fatal mistake: they immediately start the team coding. There is no time to plan, no time to document, no time for meetings, no time for reviews, and no time for unit testing. There is only time to code it, build it, pass it to QA for testing, find defects, and repeat the process until the release date. Then, someone makes a decision to either release it as is or slip the date and apply more pressure.

In this model the software manager has two primary responsibilities. One responsibility is to apply more pressure on the team to work longer and harder. The second responsibility is for the software manager to assume the role of fireman (hero): wait for problems to surface, hold a meeting, give orders, and make decisions - hopefully good ones.

Once a project is in this mode and continues to work in this style, each release becomes ever more difficult to deliver as the code base becomes more fragile with every release. Further complicating the situation is the high rate of team members exiting the company. You’re losing your best and experienced people. You’re in the death spiral. How do you fix it?

Fix this?