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.

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

http://www.geraldmweinberg.com

http://secretsofconsulting.blogspot.com

https://www.facebook.com/gerald.m.weinberg

https://twitter.com/JerryWeinberg/

https://www.facebook.com/terra.ziporyn.snider/posts/10156674749391457

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