Sunday, February 25, 2018

Thought and direct experience

Being wrong, and become aware of that, are two different instances of reality. For me, the conjunction of those instances is a joyful experience. For example, I was wrong, very wrong, about who can possibly be able to know something and teach it to others. It is good to know that I was wrong. I just recalled this because of a question about the role of a Scrum Master and direct experience on code design:

Full conversation: Honestly Curious.

«…I used to think —decades into my past— that “the only way” —careful! Bigotry alarms at full capacity here— somebody could ever know and ever teach about something is by the sole means of direct experience. Period. Simple. End of discussion.

Nowadays, —since about 28 years ago—, I reflect that the subject matter of knowing and the subject matter of being able to teach or help others turned out to be not that simple. And the discussion is wide open, and the debate keeps very active among authorities on those subject matters.

There are cases where somebody can, in fact, learn a lot from the experiences reported by others and by pure sheer thought based on sound theoretical schemes. So, now I think that a fully functional Scrum Master —or anybody, for that matter— can, in fact, help others effectively without the sole means of direct experience.

Does it make sense?»

Sunday, January 8, 2017

The growth of a feature — Twelve years later

The original «The growth of a feature» post is about twelve years old. Yet, the history of iterative and incremental software design and delivery, accordingly to Craig Larman and Victor R. Basili, began about 70 years ago.

Monday, October 17, 2016

Art vs Work

Software design & computer programming is my art, not my work. That’s why my trend is to enjoy thinking more about it and doing more of it. The referred talk by Cory House reminds me the brief note I wrote back in 2005: I like it! Also this one: I like it even more!

Becoming an Outlier, by Cory House.

Saturday, December 6, 2014

A recent survey

There is this other survey with interesting questions about challenges and strategies for successful agile methods adoption:
http://agileresearchnetwork.org/take-the-agile-in-non-agile-environment-survey/

It reminded me that I have seen, time and again, individuals and teams facing enormous struggles to understand themselves and then change values, principles and practices in their own culture in order to ship better software. In my little window of reality around, many cases look hopeless. But, sometimes, there are individuals eager to think and behave differently and who are actually looking for hints to learn new professional principles and values. For those cases, I usually give the following answers to questions like these:

Question 1: Have you encountered challenges to improve software engineering principles, values and practices?

Part of my answer: many challenges, but —this could surprise you— many come from IT people (architects and developers, and their managers) who are unwilling —or unable— to unlearn and relearn.

Question 2: Which strategies would you suggest to face the challenge of shameful levels of unprofessionalism in software development projects?

Part of my answer: We already know: there is no silver bullet. But, one sensible strategy is to start a long journey of un-learning and re-learning the own computer software career. Get back to human basics: un-learning and re-learning basic philosophical and critical thinking, deep study of philosophy of science and engineering, and other basic stuff in the Humanities; for instance, anthropological research as a preparation for doing cultural critical analysis.

Thursday, June 19, 2014

Abstraction stacks and multi-paradigm software design

Originally published in Abstraction stacks and multi-paradigm software design, 19 Feb 2004 7:57 PM.

 

Why is important to learn Microsoft Common Intermediate Language (CIL)?

In your role of software technology end-consumer, there is very little, almost non-existent need to.

In your role of software technology producer, a software designer most likely, then the answer is the same as answering: Why is important to a Daytona race pilot to know his engine?

The answer has a relationship with the eagerness of the pilot or the software designer to win!

When my CIL knowledge would be necessary?

From the very first design decision to the last pulse of the crafted bits. That is, if the software artifact is intended to last then it must be designed with that goal in mind.

It seems that most commercial software is designed with other priorities in mind, but not to last. Perhaps, that is a factor behind the reason why, sometimes, end consumers don’t buy more technology.

What is an abstraction stack?

The basic client-server model where a piece of software (the client) asks for something to another software artifact (the server) without caring what the server has to do in order to fulfill the request. This involves the server taking the client role to ask for help to another server, which in turn takes the role of client and…, you got the point.

If you think a little bit about it, an abstraction stack is endless in both directions, server and client, at least philosophically.

The microprocessor (or the running engine like CLR) can be seen as a pragmatic end of current computational abstraction stacks.

Is not the purpose of an abstraction stack supposed to isolate me from knowing all this low-level stuff?

The main purpose of an abstraction stack is to isolate software artifacts, packaging them in layers, subsystems or components of functionality in order to tackle complexity and convey design decisions at higher levels of abstraction.

It is good and desirable for a software artifact to not know the details of its server.

For a software designer, it is neither good nor desirable to not know the details of every layer, subsystem or component in a target abstraction stack.

So, at your next design decision, take in account that you do not have the luxury to not know the details of how your requests are fulfilled. Options are, either the knowledge of the details is in your head or in the head of somebody else in your very same design and programming team.

What is multi-paradigm software design?

Modern software design encompasses a broad set of techniques coming to us from several schools of thought and paradigms. Design skill comes from understanding, articulating, practicing and feed-backing concepts, methods and techniques from all those paradigms.

Multi-paradigm software design is the practice of growing the best possible software in a given context.

“Multi-paradigm design is a domain analysis technique that features concurrent analyses of the application and solution domain. The goal is to find solution domain constructs that most naturally express the structure of the application domain.” As stated by James O. Coplien in “Multi-paradigm design for C++”

If you know CIL, or the details of what ever layer of your abstraction stack, you are at a better position to take proper design decisions.

CIL is another programming language where you have more design options than popular programming languages C# and VB .NET

How this can possibly be related to my current and future job?

Software design is a very singular endeavor at its current state, a combination of art, science, craft and engineering; proper design allows maximum correctness, robustness, modularity and flexibility. Poor design guided by bogus assumptions leads to misery and despair within development teams.

Or in the words of Bertrand Meyer: "The in-the-large aspects of programming rely on the lower-level parts, and you can't get them right unless you get the small things right too"

Saturday, March 15, 2014

Obstacles to DevOps

There are several traits of this DevOps inclination that are compelling to me. One is the kind of intellectual promiscuity involved; that is, to combine perspectives of perceivably dissimilar roles in an indiscriminate way. Doing so would enhance the architectural acumen for design decisions by widening the span of attention to even more relevant matters involved is software execution.

There are a number of cultural obstacles to tackle in order to get such acumen in a software provider organization; for example, the obstacles to freely share the hard-won personal technical expertise on the sole premise that doing so is good for the project as a whole, not just good for political exchange of favors among individuals.

Another grievous obstacle is philosophic and scientific illiteracy in the midst of project leaders and team members. Such illiteracy worsen the chasm between the way words are used to map reality in the architectural drawing board, on one hand, and the daily operations room, on the other. A better awareness, for example, of how language can be used in an operational way to build meaning would help decrease the blaming noise and gibberish like ‘our system is down’ or ‘the system does not allow me to give you service’.

Language can be a tool for a clearer thinking, not just a noisy instrument for obscure utterances. A proper use of technical language is important to enhance quality by means of building meaning with sets of operations. That is, of course, there are multiple legitimate ways to use language, but teams using technical language could benefit a lot from the philosophical and historical reflection of the use of language in the sciences. More on that here: Operationalism