Sunday, September 22, 2019

Freethinking and free inquiry about software creation

I very much enjoy computer programming. I also enjoy reading authors that talk about it from diverse perspectives. Just as much as practicing philosophy and reading whoever author that talks about philosophy —taken as the basic human impulse to go deeper into what causes doubt and wonder.

So far, I would say that some mechanical and tedious tasks related to computer programming are no longer a major challenge because we now have a lot of good tools helping with those tasks. On the other hand, the intellectual challenge of computer programming remains as a major challenge even today. Of course, now many good lessons are at reach, lessons from thought and experience of the last seven decades. But the intellectual challenge of non-trivial software endeavors remains in the category of major intellectual challenges.

Freethinking and free inquiry about the historical development of software creation is still worthwhile: which theses –or which aspects of them–by original authors are still current? How far I am able to articulate now those main theses of the field?

«At the time I was being groomed to become a very good theoretical physicist, but in 1955 that training was aborted when I decided to become a programmer instead. Not suffering from excessive modesty, I had what I considered a very good reason: I had concluded that programming presented a greater challenge than theoretical physics.»

Under the spell of Leibniz's Dream. Prof.dr Edsger W.Dijkstra.

«I felt that my problems as a programmer were for a large portion beyond the scope of what Polya covered. At first I hesitated to say so aloud, because stressing the exceptional nature of the one's field is usually a sure way of making oneself utterly ridiculous. But after careful consideration I concluded that the intellectual challenge presented by the programming task is, indeed, as unprecedented as the high-speed automatic computer itself.»

"Craftsman or Scientist?" prof.dr.Edsger W.Dijkstra.

Saturday, September 14, 2019

Writing good software

Writing good software takes time and a lot of practice, diverse concepts, values –like diligence–, a lot of patience, and other skills. It is kind of similar to master a musical instrument.

It is good to take time everyday to learn and practice: write working code everyday.

Just like music, first you write code everyday to implement usual algorithms (searching, sorting, etc.) by yourself.

Eventually, you gain enough skill to start your own little compositions.

Sunday, September 16, 2018

All great systems are made by great people

About great people as the actual source of great systems, I think we should go deeper on what entails to be called “great”, both, people and systems. The act of design, and its related dexterities, is one factor towards such professional greatness. Much of these questions have been thoroughly researched by many authors. I have quoted one of them in the following old post: Good designs come from good designers, good designers come from....

Furthermore, great people are required for great systems on both closely related realms: technical and management. Great teams grouping individual designers of all sorts of artifacts, e.g., test cases or executable software components, should afford great data processing systems; likewise, management should afford great organizational systems as supportive environments for those teams.

Gerald M. Weinberg —and many others— have already pointed out that the history of software development is paved with failed attempts to realize gains in quality and productivity without first creating a supportive environment. To improve bad situations, many managers spend their money on tooling, methodologies, outsourcing, training, application packages, etc., but they rarely spend enough to remove the management that made those situations in the first place or they hardly spend enough to improve them.

As Gerald M. Weinberg also said, we —software developers— have always been a would-be profession, and we will remain a would-be profession until we outgrow our obsession with quick fixes that don’t involve fixing the managers themselves.

Of course, as the saying goes, «you’ll never clear the water until you get the hogs out of the creek». But, let’s be crystal clear: such hogs are not bad people, but bad ideas. In other words, many underlying theories of software development management are obsolete; including many theories of project management.

This is already known since decades ago. I just recall an old post about it: The Underlying Theory of Project Management is Obsolete.

Saturday, September 15, 2018

Back to basics: Demanding reading

The following article came to my attention: The Satir Change Model.

An article that includes references to the works of Virginia Satir and Gerald M. Weinberg is a promising reading. Of course, the direct reading of the seminal works by those authors –among other luminaries– would be the best reading. Though the closer to the seminal authors, the more demanding the reading would be.

That kind of demanding reading is what I am talking about when I say that we —our profession— need to go back to the basics.

Saturday, August 11, 2018

Gerald M. Weinberg

One of the finest thinkers on computer software development has passed away on August 7, 2018.

« scientist, author and teacher of the psychology and anthropology of computer software development.» Wikipedia

Saturday, August 4, 2018

Reading and digesting classical authors

You just narrated part of my story exactly! But there is a second part of my story that led to my current ‘reflective’ stage in my professional career on software design. That second part includes reading and digesting some other kind of texts by classical authors (Dijkstra, Dahl, Hoare, Knuth, Meyer, Tanenbaum, Myers, Mills, Weinberg, Parnas, Gilb, DeMarco, Abelson and Sussman, etc.). This current stage feels like another career entirely different than the career in my previous part of my story. Nowadays, I talk to others about that in the context of my Reflective Developer Program’.

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?»