Controlling and Documenting Software Development: a new approach

I’ve been reading a Tom de Marco’s article these days, where he reconsiders the “You can’t control what you can’t measure.” phrase.

http://www2.computer.org/cms/Computer.org/ComputingNow/homepage/2009/0709/rW_SO_Viewpoints.pdf

“I’m suggesting that first we need to select projects where precise control won’t matter so much. Then we need to reduce our expectations for exactly how much we’re going to be able to control them, no matter how assiduously we apply ourselves to control.”

Another great piece is the 1997 Bertrand Meyer’s satiric article. It is undoubted joking but most of it fits real and up to date for me.

http://archive.eiffel.com/doc/manuals/technology/bmarticles/uml/page.html

“In its attempt to show that it has included everyone's pet ideas, it is a chock-full of symbol after bizarre symbol. Just the "Notation Summary" takes up 60 pages and has its own table of contents! UML is in fact as complex as a big and cryptic programming language, with generous use of "$" and "#" and "-" and "*" and "solid triangles with no tail" and rectangles and diamonds and solid lines and dotted lines and solid ellipses and dotted ellipses and arrows of all kinds and keywords such as "const" and "sorted" (not to be confused with "ordered") and different semantics for a class depending on whether its name appears in roman or italics; but at least a programming language, even the worst of languages, is executable! Here you have to learn all this monstrous complexity just to build diagrams of a possible future system.”

“For example I have tried to see if I could characterize UML as "object-oriented"; we all know this is a great compliment. Fat chance. Of course the authors make the requisite use of "object" and "inheritance" and so on. But a mere glance at the diagrams shows UML for what it is: an extension of entity-relationship modeling. The basic examples show binary and ternary associations, such as (page 16 of [1]) associations between "flight" and "seat" and "person"; this is the exact opposite of object-oriented design, where, as we all know, the world is structured in classes, built around object types, and every operation or property belongs to one class. Surely in object-oriented design you can't have a "passenger" link that treats "seat", "flight" and "person" symmetrically! In an object-oriented system it would belong to one of the classes; that's how you obtain the consistency, simplicity, modularity and reusability of O-O architectures; look at BON or at Eiffel to enjoy the results. The authors of UML know this, of course; to understand why they call UML object-oriented we must appreciate their famous sense of humor. Obviously they meant it in jest.”

“How could I criticize the method for not helping software developers or managers, when it does not care about software development at all, but only about developing a market for consultants and trainers? Everything started to make sense: the complexity and bizarreness of the notation, which I had foolishly taken for a deficiency, are in fact among its most attractive qualities, since they make for endless business opportunities, for Rational and perhaps even for others as well; so does its lukewarm adoption of object-oriented ideas, since it means a consultant does not even have to like or understand object technology to profit from UML.”

My growing interest on agile philosophy and methodologies, trying to convince my job mates (all levels), to give the software project control and documentation a much more soft touch, the Design By Contract approach sounds much more smart and agile to me now.

I like so much this practical approaching article:

http://devlicio.us/blogs/billy_mccafferty/archive/2006/09/22/design_2d00_by_2d00_contract_3a00_-a-practical-introduction.aspx

So, in the control and document software development subject, we have:

The don’ts (old fashion):

• Instead of hard control software development, try to deliver software that makes a difference.
• Function Points is not an effort estimation method; don’t try to estimate time spent using it.
• If the average managers try to deliver software on a seni
• or developer time line with a bunch of junior or even trainee developer team, why in the Earth do we need to over control software development? And worst, why to use FPA to measure it.
• Since UML is not simple, agile, or even OO, why in the Earth do we need to use UML when modeling or documenting software development?

The Do’s (new fashion):

• Manage the people and control the time and money.
• If you want to control something in software development, control its quality.
• Use Mind Mapping to barely document the software requirements (user stories).
• Use DbC to design the software.
• Use a smart and agile (like Rails) technology to implement it.
• Use XP methodologies when implementing it.
• Applying BDD, use executable specification and documentation techniques.
• If there is an obligation on measurements and control, use an agile technique like “AgileEVM” for instance.

And remember: what really matters to the customer is:

“BUSINESS VALUE DELIVERED PER SPRINT”

So, that is exactly what we need to focus on.