Ahmed’s Dev-Shop

Pigs & Chicks

Posted in programming, software by Ahmed Siddiqui on June 16, 2008

I couldn’t stop myself laughing out loudly when first time I came across the following paragraphs about some Roles defined in Scrum —an Agile development modal.

 

Several roles are defined in Scrum; these are divided into two groups; Pigs and Chickens, based on a joke about a pig and a chicken.

A pig and a chicken are walking down a road. The chicken looks at the pig and says, “Hey, why don’t we open a restaurant?” The pig looks back at the chicken and says, “Good idea, what do you want to call it?” The chicken thinks about it and says, “Why don’t we call it ‘Ham and Eggs’?” “I don’t think so,” says the pig, “I’d be committed but you’d only be involved.

So the pigs are committed to building software regularly and frequently, while everyone else are chickens that are interested in the project but are really irrelevant because if it fails they’re not a pig, that is they weren’t the ones that committed to doing it …

 

The misfortune is that sometimes projects are implemented with the above incomplete and unbalanced specification. Following is the remaining part of this paragraph:

… The needs, desires, ideas and influences of the chicken roles are taken into account, but not in any way letting it affect or distort or get in the way of the actual Scrum project.

 

Responsibility and Influencing Power should meet at an equilibrium point just like Demand and Supply in economics. Otherwise if you are changing x, you are implicitly changing y. And if you think you can control it, just give it a try.

http://en.wikipedia.org/wiki/Scrum_(development)#Scrum_roles

Laws of Systemantics by John Gall

Posted in Engineering, software by Ahmed Siddiqui on May 15, 2008
  1. The Primal Scenario or Basic Datum of Experience: Systems in general work poorly or not at all. (Complicated systems seldom exceed five percent efficiency.)
  2. The Fundamental Theorem: New systems generate new problems.
  3. The Law of Conservation of Anergy{sic}: The total amount of anergy in the universe is constant. (“Anergy” := ‘human energy’)
  4. Laws of Growth: Systems tend to grow, and as they grow, they encroach.
  5. The Generalized Uncertainty Principle: Systems display antics. (Complicated systems produce unexpected outcomes. The total behavior of large systems cannot be predicted.)
  6. Le Chatelier’s Principle: Complex systems tend to oppose their own proper function. As systems grow in complexity, they tend to oppose their stated function.
  7. Functionary’s Falsity: People in systems do not do what the system says they are doing.
  8. The Operational Fallacy: The system itself does not do what it says it is doing.
  9. The Fundamental Law of Administrative Workings (F.L.A.W): Things are what they are reported to be. The real world is what it is reported to be.
  10. Systems attract systems-people. (For every human system, there is a type of person adapted to thrive on it or in it.)
  11. The bigger the system, the narrower and more specialized the interface with individuals.
  12. A complex system cannot be “made” to work. It either works or it doesn’t.
  13. A simple system, designed from scratch, sometimes works.
  14. Some complex systems actually work.
  15. A complex system that works is invariably found to have evolved from a simple system that works.
  16. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over, beginning with a working simple system.
  17. The Functional Indeterminacy Theorem (F.I.T.): In complex systems, malfunction and even total non-function may not be detectable for long periods, if ever.
  18. The Newtonian Law of Systems Inertia: A system that performs a certain way will continue to operate in that way regardless of the need or of changed conditions.
  19. Systems develop goals of their own the instant they come into being.
  20. Intrasystem{sic} goals come first.
  21. The Fundamental Failure-Mode Theorem (F.F.T.): Complex systems usually operate in failure mode.
  22. A complex system can fail in an infinite number of ways. (If anything can go wrong, it will.) (see Murphy’s law)
  23. The mode of failure of a complex system cannot ordinarily be predicted from its structure.
  24. The crucial variables are discovered by accident.
  25. The larger the system, the greater the probability of unexpected failure.
  26. “Success” or “Function” in any system may be failure in the larger or smaller systems to which the system is connected.
  27. The Fail-Safe Theorem: When a Fail-Safe system fails, it fails by failing to fail safe.
  28. Complex systems tend to produce complex response (not solutions) to problems.
  29. Great advances are not produced by systems designed to produce great advances.
  30. The Vector Theory of Systems: Systems run better when designed to run downhill.
  31. Loose systems last longer and work better. (Efficient systems are dangerous to themselves and to others.)
  32. As systems grow in size, they tend to lose basic functions.
  33. The larger the system, the less the variety in the product.
  34. Control of a system is exercised by the element with the greatest variety of behavioral responses.
  35. Colossal systems foster colossal errors.
  36. Choose your systems with care.

How to get the worst of all worlds

Posted in Uncategorized by Ahmed Siddiqui on April 10, 2008

 
This is the story of ancient war between Software Scientist and Software Craftsmen on the ground of Software Engineering
The Scientists

Slogans:
   Let’s reinvent the wheel
   Complexity is charm

   Think out-of-the-box (never look inside)

Whenever company gets a project the developers are in search of well-hyped patterns and practices. Whatever the projects require, whatever the timelines are, they follow impressions, seeking complexities to passionate their lives. The problem is they want to combine the universal truths they get from their gurus, with the hypes. They get the compliance in few of the cases. It becomes a routine that start with complexity and when you stuck, let the things fly.
They often suggest the solutions they think they should learn. According to their point of view: software projects are to create a difference, even if the project fails, even if they do not add any value, if they implement state-of-the-art technologies, they consider it success.

The Craftsmen: the delivery people
Slogans:
We deliver
Quality is just a fantasy, don’t talk about it
Ad-hocism
Research is a synonym of time-wasting;


Fortunately some of the projects who comply with hyped patterns and rigid practices succeeded to achieve the timelines, thanks fortune. And now the support people are ready to show their quick solutions. They’ll show that the tasks completed by the developers in month was just a matter of days. Thanks to encapsulation; no one knows what’s inside J

Till the day the application is safe from the quick solutions of support staff, it shows some stability. And once it gets the first JUGAR—synonym for a careless ad-hoc solution in Urdu language—the application becomes more addicted to their JUGARs and provides more options for support people to prove their problem solving skills.