Tuesday, 2 December 2008

Why the Software Industry is sucking more and more

With inflation and pollution come ignorance and even more confusion...

To begin with, the A in the ABC of software production:

It is not about doing it right, it is about doing the right thing!

Software is about the conceptual side and only marginally about the technicalities. About using our mind, sensibility and intelligence to provide a reliable and competitive product and service to people.

This is certainly clear to our customers: information technology is a wonderful tool, yet an enabler, never a driver. This is seldom clear to present-day software managers and even developers, who should rather realise that the matter in question is predominantly conceptual even at the lowest levels.

Saturday, 20 September 2008

Yet another argument: against test-driven

Mr Jason Gorman, in his post "Test-driven Enterprise Architecture" (September 16, 2008) [*], writes:

I've discovered that the most effective way to align business goals with the software and systems we deliver is through heirachies of tests, not through pretty pictures and dotted lines.

I have to disagree, essentially. It is certainly true that most of those dotted lines get drawn without criterion, which is indeed what makes the difference between an *analysis* and a bunch of dotted lines...

On the other hand, tests cannot drive solution development: the problem domain and the solution domain just do not map one-to-one to each other, rather the latter is a sub-product of the former. In practice, as information engineering teaches, the solution domain emerges out of the opportunities for automation identified within process and data models at the business level. Here is a distinction, just like the distinction between syntax and semantics, that must not be neglected, otherwise not only the understanding but the very quality we are after is gone, with all that in fact counts.

[*] http://parlezuml.com/blog/?postid=693

Monday, 14 April 2008

If I jump into a Ferrari and... run away?

Ok, let's suppose somehow I get around the boxes of an F1 circuit at the time of a race: difficult surely, but if you take into account a bit of luck, pretty doable.

Let's then suppose somehow I manage to find an F1 car in the proper conditions, that is as much ready to start as needed: so difficult that, again, with a bit of luck, it is definitely possible.

Let's finally suppose I manage to start and go: not so difficult, above all if I have *trained* hundreds of hours in a proper simulator...


Wow... let's assume I wake up from a crash at the very first bench after the start. Hmm, what has gone wrong?

Flash-forward, watching TV in London: in a show called Top Gear [*], a journalist is to have a try at driving an F1. He has some previous *experience*, so they first let him try a lower formula, so that he can prepare to the F1 experience. He is not that fast but quite comfortable on the F2, but at his first attempt on the F1, that is, after he manages to start the car, he is not even able to go as fast as to keep tires in temperature. At his second attempt, and not before some magic from the mechanics, he does it; funny driving, anyway he is able to complete his 2 laps with no more damage than a couple of testa-coda in the smaller benches.

Bottom line: simulation doesn't sum up to competence, and I'd rather go into journalism than try some more training.

Indeed, do not steal a Ferrari, just *** it.

[*] Richard drives a F1 car round Silverstone - Top Gear - BBC (YouTube version)

Thursday, 27 March 2008

On readability -- Pure induction in action

Radical engineering principle: on readability


Engineering principles are true by good convention.


Optimal "readability" is readable _optimality_.


Never ever optimize. <*>

Do make code readable. <**>

Clean up the dark side. <***>

Readability before all. <****>

The only way to optimal code. <>


<*> Includes refactoring, the semantic side of optimization.

<**> Includes restructuring, the semantic side of readability.

<***> Includes comments, the dark side of readability.

<****> Includes the dark side of optimality.

<> Readability dis-including itself.


Optimization of a sub-optimal program (algorithm, system, product, procedure, argument) is a pointless hack that leads to solutions at local minima. Improvement of such local-minimal solutions is impractical, given that the underlying landscape is so redundancy-reduced as to result completely chaotic.

In practice, if a sub-optimal program gets optimized (once upon a time there was the blessed post-optimization-upon-need, nowadays we have optimization as an integral programming practice called refactoring and its cousin performance), any required improvement needs stepping back tot iterations until another approach, more basic but broader enough for the extended problem, gets in sight. The more premature the optimizations, the more paralyzing the sub-optimized local-minimal results. And the iteration starts over...

To break the deadly cycle, just stop optimizing in any form, start instead striving for readability. To get a basic idea of readability, we can think of the optimal target as a program code that can be _read as easily_ by a professional in the field as something in between a technical article and a page of mathematics. That is, code must speak for itself!

[A side note to the casual reader: please don't get too strict on terminology, I'm using all terms in their _broader_ sense, so that, for instance, should you be a software engineer, where I say "coding", I actually mean any act of production, including all that there is from analysis to delivery. The same holds for other disciplines. The only restriction is maybe in that I try to stay within the bounds of "engineerings" and "applied sciences", although, sooner than later, we'll catch up with "social sciences"...]

That said, apart from avoiding the inconveniences of optimization (taken in its broadest and weakest sense), readability brings its own distinct advantage, indeed an exclusive property: readability and only readability leads to optimal programs. We still miss a formal proof, but this might be apparent if we think what an _optimal_ program is: on a side, readable entails manageable so much as the latter requires the first; on the other side, every _ideal_ relates to needs that, in any ultimate sense, are "human" and only "human". Indeed, "who" needs _what_?

[For example, say one is programming and keeps readability in mind.
That means:
1) writing code with readability in mind (rather than "writability");
2) designing a system under permanent (re)structuring, down from its very (im)permanent foundations;
3) keeping the whole environment always clean and tidy, as if important guests are to arrive at any moment soon (and that includes documentation; yes, please, if in doubt, just DROP IT ALL!!).
That leaves plenty of room for movement, and the code stays always around the optimal balance between minimality and continuous improvement.]

We can't predict the future, we make it: we are pure induction in action.

Tuesday, 12 February 2008

On correctness -- Correct is Good!

Radical engineering principle: on correctness


Engineering principles are true by good convention.


Correct is good! Period.


As far as it passes systems testing, a system is "correct", and the problem becomes "good" testing.


We do solve the halting problem in everyday life, though asymptotically: up to the next failure.


Consider the full set of systems for a given problem: IS* = S + oo + 0/0, where S is the set of bounded correct systems, oo is the set of full-correct systems, and 0/0 is the set of failing systems. IS* so defined can be treated in terms of interval arithmetic.


G.W. Walster, "Introduction to Interval Arithmetic", 1997 (slightly adapted):

The interval paradigm has a number of valuable characteristics, including:
1. Fallible data can be represented using intervals.
2. Any arithmetic computation can be performed with guaranteed bounds on the set of all possible results.
3. Bounds can be provided on errors from all sources:
  • observation or measurement errors;
  • modeling errors;
  • machine rounding errors; and
  • interactions among all of the above and the inherent instability of the problem.
4. Problems can and have been solved that are otherwise thought by many mathematicians, scientists and engineers to be in principle unsolvable. Exemplars include:
  • nonlinear systems of equations; and
  • nonlinear programming (or nonlinear global optimization).
For additional information on interval arithmetic and how it can and has been used to compute guaranteed bounds on answers to otherwise unsolvable problems, see:

[*] As an alternative link: http://web.archive.org/.../walster-papers.html


Thanks to the invaluable support I got from the sci.math group (no endorsement implied): Computing infinity modulus and zero modulus.

Monday, 11 February 2008

On refactoring -- You should clean up!

Radical engineering principle: on refactoring


Engineering principles are true by good convention.


You shouldn't refactor, you should clean up!


You can refactor when finished, i.e. never.


Clean up before and after yourself.


You can be many, but you can't be one.