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:

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

Sunday, November 10, 2013

Why a Reflective Developer Program?

I have written down the rationale behind the Reflective Developer Program in the following pages, ending with a brief introduction to the program:

1. The state of software development in some trenches.

2. Agile impressions.

3. The Law of Raspberry Jam.

4. Learning from other communities of inquiry.

5. The Reflective Developer Program - what is it about?

4. Learning from other communities of inquiry

There are a number of works on epistemology —as philosophy of science— and on general theory of knowledge —or gnoseology, as known in some Latin-derived cultures— that have been very significant on my research. For example, Ernst Cassirer’s works study knowledge as a philosophical problem and its implications on the development of human culture:

- The Problem of Knowledge.

- The Philosophy of Symbolic Forms: Vol. 3: The Phenomenology of Knowledge.

- An Essay on Man: An Introduction to a Philosophy of Human Culture.

The philosophical perspectives predominate over strictly scientific perspectives in Cassirer’s works. I have found a more balanced treatment between philosophy and science in Mario Bunge’s two volumes on epistemology:

- Philosophy of Science: From Problem to Theory.

- Philosophy of Science: From Explanation to Justification.

Introductory works more on the side of strictly scientific perspectives that I have found very helpful are:

- What Is This Thing Called Science? by Alan F. Chalmers.

- Scientific Method in Practice by Hugh G. Gauch Jr.

- Theory and Reality: An Introduction to the Philosophy of Science by Peter Godfrey-Smith.

Then, there is this contemporary scientist, Rupert Sheldrake, who —as Paul Feyerabend in his own time— presents quite intriguing, or even interesting, arguments that shake popular understanding of scientific thought in his work:

- Science Set Free: 10 Paths to New Discovery, USA Edition.

- The Science Delusion, UK Edition.

Among the first works that indirectly pushed me to all the mentioned readings was this:

- Testing Computer Software, 2nd Edition by Cem Kaner, Jack Falk, Hung Q. Nguyen.

All this, and the following works by Donald A. Schön, has led me to pursue the development of what I have called a Reflective Developer Program, as a contribution to better professionalism in software development. A reflective developer is someone who tries to realize how thin her received piece of jam really is, and tries to make it thicker.

- The Reflective Practitioner: How Professionals Think In Action.

- Educating the Reflective Practitioner: Toward a New Design for Teaching and Learning in the Professions.

The Reflective Developer Program is intended to be a personal research journey to better understanding of professionalism in computing. Given the philosophical problem of knowledge and The Law of Raspberry Jam, I think that teaching and learning in our profession need to be rethought. Therefore, after studying the following works, I have found that dialog and discussion among practitioners is the appropriate thing to do.

- Turning Learning Right Side Up: Putting Education Back on Track by Russell L. Ackoff, Daniel Greenberg.

- Up and Out: Using Critical and Creative Thinking Skills to Enhance Learning by Andrew P. Johnson.

- Discussion as a Way of Teaching: Tools and Techniques for Democratic Classrooms by Stephen D. Brookfield, Stephen Preskill.

- Developing Critical Thinkers: Challenging Adults to Explore Alternative Ways of Thinking and Acting by Stephen D. Brookfield.