On the "software crisis"

I would start from the fact that software production is an industrial, long-term endeavour: just think reuse (aka configuration management), which is only one component of a whole picture, and already that should remind not only the level of complexity (complexities!) involved, but, even more importantly, that an efficient and highly successful production unit (not just a successful project) is not an occasional target and cannot be!  (Indeed, that is why it was called "development".)

Currently, what I see is a general trend of naming "agility" what is actually a quest for the ultimate (worst) RAD and the ultimate (over-)simplification: and that is the clash of industrial vs. commercial [but, more and more so, also the overall economic and financial] cultures and strategies.  What has happened starting with the so called democratisation of programming is, so to speak, that our customers have taken our place!  In practice, building software has become feasible to everybody, with the result that most technical offices are literally up-side down, and the whole marketplace has been seriously [if not irremediably] diluted.

But, as noted initially, software production is a most complex engineering and requires highly sophisticated and specialised competences, to the point that plain common sense (the "magic recipes", invariably just out of the social-mediatic hat) just will not cope.  Indeed, software engineering is the *most* complex engineering that there is, to the point that the majority of its fundamental notions are genuinely counter-intuitive: as a result, plain common sense not only is utterly inadequate, it is actually doomed to failure.

Bottom line, I believe most of today's agility is a cover-up for what is in fact pure plain RAD, and the software crisis is a myth and a spell that can be (easily, to say) dis-solved: just there is an essential distinction to make, between proper and improper software production, with the vast majority of the software endeavours nowadays belonging to the latter category. Then, and just to begin with, the very shape of the industry-specific performance surveys would change... In fact, I would claim that proper software developers (and, scaling up, proper software production units) do, already today, consistently provide near to optimal results, all environmental circumstances considered!

Software craftsmanship

"Crafting the details" to me evokes hours spent filling in the little gaps and cleaning up, while rethinking the whole thing over and over again. Hours when few lines of code get written, yet the overall quality and understanding improve dramatically. I was thinking how much I value and do it...

Software craftsmanship is when we
spend at least 20% of the project time
crafting the details.

Posted to the Software Craftsmanship user group:
http://groups.google.com/d/topic/software_craftsmanship/5AEub97Mr2k/discussion

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 an effective and reliable product and service to people.

This is certainly clear to our customers: Information Technology is a wonderful tool, yet an enabler, never a driver [except that even this is now failing, courtesy progress up to Industry 4.0 (2023-11-09)]. 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.

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

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, especially if I have *trained* for hundreds of hours in a proper simulator...

...brooOOEBY*&CROXZYQNRX8-7pVWOaei72)D9####F[---

Wow... let's assume I wake up from a crash at the very first turn 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 F3, 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 two laps with no more damage than a couple of testa-coda in the smaller turns.

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 (YouTube)

TicTacToe 1.2.B released for preview

TicTacToe 1.2.B has been released for preview.

« Tic-tac-toe is a classic case in the field of computer science, though our primary goal here is to investigate software development concepts and practices, and infer engineering-level indications to formal methods and patterns of construction. »

Contents:

1. Iteration zero and beyond
2. Top-level design and source code
3. Next open issues

Read the full document here: TicTacToe 1.2.B / Docs

---

TicTacToe is an open project.
You are encouraged to
send questions and feedback, and
ask more about getting involved
to ThisTeam's box:
thisteam@julio.diegidio.name

---