Prioritizing backlog items: a checklist

23/08/2018

When planning what is the next thing to do, for each project or sprint backlog item, I ask myself or stakeholders a number of questions. Below are some of them:

...

If it is:

• nice-to-have,
• something that we "eventually need to do",
• low-risk,
• low-priority,
• something without a clearly articulated use case,
• something that will not be used immediately,

Software team collapse: game of jenga tower

22/08/2018

Unlike the uncontrolled rot of software project motor neuron disease, jenga tower game is a deliberate game of "business optimisation" and "productivity improvement":

The team operates and delivers, thus, pull a piece out of it (delay a salary review, increase the workload, withdraw the monthly cake money): If the team still functions, it reinforces the management's conviction that their approach is correct and even somehow akin to the scientific experiment and lean approach as good as other industry best practices. Pulling a piece out - getting productivity "gain" looks like a cause-effect relation.

Software project collapse: modeled after motor neuron disease

28/03/2018

It's an antipattern:

They say by the time the motor neuron disease sufferer feels he has difficulty of moving his arm, 70% of his arm's neurons already have been destroyed.

It's the same with the software project or software team: the higher management, as it happens most of time, ignores structured communication with the software team, by the time they realize that the project or the team cannot function anymore, 70% of it is in irreparable damage.

Deployment bias

29/01/2018

It's similar to and yet different from the implementation bias in how it relates to coupling, one of the most expensive things in software development. Deployment bias lies at the core of the lean bias, too.

The third skill

25/01/2018

"Project Oxygen shocked everyone by concluding that, among the eight most important qualities of Google’s top employees, STEM expertise comes in dead last. The seven top characteristics of success at Google are all soft skills: being a good coach; communicating and listening well; possessing insights into others (including others different values and points of view); having empathy toward and being supportive of one’s colleagues; being a good critical thinker and problem solver; and being able to make connections across complex ideas."

...

What still is sorely missing is the acknowledgment of the third type of skills: formal understanding of the language from the software point of view, i.e. wielding the theory and practice imposed by expressive/performative structure of language, which qualitatively different from science or maths skills and which is not taught in any hands-on way as a part of humanities curriculum.

Don't reply e-mails and other communication tips

31/07/2017

To be efficient, the technical aspect of communication needs to be crafted and perfected on all its levels in the same way as the software code. It is not inherently bad, when the communication is fluffy and informal. It is likely to make it more warm in the human sense. However, seeing communication as a soft skill without structure or method has a high price tag: excessively long discussions, confusion, misunderstandings, echo chambers. Some companies can afford it and some decide they cannot.

Preserving capabilities

28/11/2016

Agile is heavily oriented towards product output. The lean analysis is focused on value flows in the organization, which results in the (incremental) output of usable products with the process and inventory as light-weight and disposable as possible.

Nevertheless, even if the software team is temporarily assembled for a one-off stint, even if the product is too specific for any reuse, separating features from capabilities, separating building capabilities from their deployment, and deployment of capabilities from their placing is an essential step of software design...

Principle of two extremes: no golden middle

22/09/2016

Principle: When designing or naming an artifact, be as generic as possible. If you cannot, be as specific as possible.

Of course, it's good to be generic: less work in future. However, if a class or library does not generalize well, but still is necessary for the system one develops, generalizing it just to some degree usually creates more trouble than leverage in future due coupled implementation and sloppy naming, and the latter is a recipe for inconsistent semantics, which will immediately start growing around the badly placed artifact.

Also, if the artifact seems to be mid-way: although specific to a certain project, but possessing useful generic features, it usually means that it is not decoupled properly and could be further decomposed into its generic and specific elements...

Give me everything and I will pick what I need. Enlightenment bias. Principle of ignorance

05/08/2016

It is a common fallacy in software development: you hear it from the clients, you hear it from the managers and marketing, and you hear it from the engineers: give me everything and I pick what I need.

A team lead throws the project specification (all the 2000 pages) over the fence to the engineer: read it and you will know what is required from your component. Or the himself engineer says he has to have a general project overview before he can start writing any code.

The code gets written so that one needs to read every line of it to understand what it is doing...

Bugs and weeds

15/07/2016

There are software bugs, which are functional and programmatic mistakes in the code. And there are software weeds...

Software engineering and humanities

2013

A concept is an action. The software code is the best illustration of it: by saying something it necessarily does something. Any sentence we write in python or C++ is meant to be executed.

In the human speech, John Austin called such sentences performative, the idea he introduced in 1955. For example, by saying: I declare you man and wife, a priest actually does make a couple husband and wife. He performs an action just by saying the phrase...

Code as two texts

2013

I am strongly convinced that the developments of the last hundred years in philosophy and linguistics could give a big boost to the software engineering at all levels. It is absurd that the software engineers by definition deal full-time with the artificial and natural languages and yet they wield practically no linguistic appartus in their daily endeavour.

Many if not most programmers know nothing about the simple and powerful concepts available: they are not taught them, there are no books on such knowledge, and the things that already have found their way into the programmer's psyche - like pattern languages, object orientation, agile methodologies, etc - are often misconstrued, since mechanics behind them are not exposed to the practicioners...

Architectureless design

2013

When one designs software, what comes out of it? An architecture, is not it? Or is it? The word "architecture" applied to software drags has so many distorting connotations that I am trying to consciously expel it from my vocabulary.

The architectural approach assumes a vision of the system where its components connect, interact, build on top of each other, to form the whole edifice functioning as one organism. Such a vision maybe important in a project, but only as, well, a vision rather than the master blueprint from which the system eventually materializes...

Staying in touch. Performative negotiation

2013

The quiet concentration time is central to our profession, but it only exacerbates the peril of the overfitting of the code to a specific use case, which is almost a definition of coupling. The implementation bias kicks in. To get a second use case or second pair of eyes, the programmer has to stop doing and talk instead. Frequent and structured face-to-face code reviews are not so much for catching bugs, but for fixing the expressive aspect of software, making it more meaningful, i.e. usable and intuitive in more contexts. Thus, stop doing and talk.

On the other hand, a purposeful software discussion should transform a set of practical inputs into a list of concrete actions, which would produce decisive results and pose problems for the next conversation. Thus, stop talking and do: write an artefact to look at during the next conversation.

Brought to the extreme, this process becomes continuous: any action is accompanied with a talk, or rather expressed in it. I call this style of work "performative negotiation": any discussion or negotiation is about the meaning of a concrete productive action in a given context. We articulate any action as we perform it...

Matter of scale

2013

There is no right or wrong in software, only cheap and expensive.

It may look like a strange statement. The artificial languages seem to be epitomes of logic: if a conditional expression is false, when it is supposed to be true, then it is wrong, isn't it?

However, because the meaning of software is in its usage, it cannot be right or wrong in itself...

Principle of inverse encapsulation

2010

Principle: Understanding how the whole system works is as much an implementation detail as an implementation detail encapsulated in a class.