Blog

In essence, Dreams and Details is the leadership model and way of strategy for the 4th industrial (digital) revolution. A revolution about making software a core competency of your company. 

Highly likely most of your current corporate IT and device software is more of a supporting rather than a differentiating function. Hence don’t assume that this is the way modern software goes.

Core competency means that you need to own it. You cannot delegate it to a software vendor, neither can you transfer it to a software house, consulting company or any outsourcer. Core competency is your competitiveness. 

In the beginning, every company developed their software. They were competent in doing so. The computer manufacturer developed only the operating system. Over the last 50 years, software development competency trickled out of the companies. Now it has become so simple that companies can take their fate into their own hands again. And so, they must to stay competitive. Competitiveness cannot be left to the ranks. It is the utmost duty of the company executives. 

But execs feel uncomfortable with software since they don’t understand it. This must change if you want to remain relevant. This select list of software essentials should give you a head start for your learning (upskilling) exercise.

Profit & Loss Considerations

There is no production costs in software; it is an immaterial good. There is no manufacturing involved and in consequence software margins are close to 100%.

Software has operations costs, computers to run on to be specific. Software and hardware incur management costs. With the cloud, you can turn CAPEX into OPEX. 

Different too is software-accounting. Software development costs can be capitalized, and software licenses can be treated differently than software services. In case of software licenses, you can also ask for maintenance fees which are to be accounted pro-rata. The easiest would be to refrain from software licenses and maintenance at all by selling software only as a service. 

“Physical Laws”

Engineering in software is a misnomer. Although best practices for software development have evolved considerably, it still cannot be (mathematically) proven that a software piece is free of errors. This has far-reaching implications for the quality assurance (for example there is no PPM for software). Practising frequent releases has turned out as an effective means to ensure software quality. (See here)

Semantics and software don’t correlate. Software doesn’t know the difference between currency and weight, for example. It can’t say whether a specific sequence of characters is a customer or a supplier number. (By the way; semantics are not only dependent on content of a field but also on how it is treated in the various pieces of software.) This is the reason why making different software pieces work with each other is so hard. 

Software design is much harder than hardware design. The design of physical goods is constrained by the laws of physics and by the availability of required parts. The design of software is nearly unconstrained (people are saying “in software everything is possible – it is just a matter of time and money”). This means that the number of features and content of functions of software are arbitrary decisions of human beings. This is the number one complication in today’s software undertakings of companies. If you are striving for consensus, the chances for mediocrity are high. If you are applying dictatorship, the risk for non-acceptance are high. You cannot pay too much attention to this leadership challenge.

Management Principles

There is always a next release in software. There is always an upcoming version. As a consequence, it doesn’t matter whether a particular feature is in this, or the next release provided their frequency is high enough. Hence you always want to keep some people assigned to each software piece which is still living.

Software can be repaired instantaneously. In particular, cloud software can be changed on the spot. When worse comes to worst, software can be reset; i.e. in minutes you can run again the version from before. Compare this with the infamous callbacks in the car industry. This is a very elegant way to hedge your risks. 

Specifications for software requirements are fundamentally flawed. Due to the immaterial nature of software, business people and developers have no common language. This makes it virtually impossible to write functional specifications. Better you work with a so-called living specification[1]. Meaning that you always should look at running software when approving something.

The effort estimation of software development is non-intuitive. Intuitively you would say that a more significant requirement takes more time. But in software, this is not the case. Even considering that you would source a lot of the infrastructure and generic software, it can be tough to go the last mile of building software for your competitive edge. In particular, software integration must not be underestimated (see also above). As a rule of thumb, don’t hesitate to cut back your perceived requirements by 50% to get something out the door at all. The best would be to forget about estimations at all and just evolve your software incrementally.

Proven Practices

Frequent releases mature software. If there would be one leading indicator about your software performance, then it would be how often you release it to users. This is the figure which determines everything! For more on this matter see my recent post here. 

Software needs to be continuously refactored. Code refactoring[2] is unavoidable though it eats developers time. Because if your technical debt[3] grows too large, you cannot move anymore. Hence don’t forget always to put aside some time for refactoring. 

Small teams progresses the fastest with software development. Due to its immaterial nature, the software design needs to materialize in the heads of the participating people — the more abundant the team as more laborious to accomplish this prerequisite. Hence don’t start with large groups. In the beginning, 5-10 people is good enough. And then go to 30-40 people per software piece. And then spawn a new piece. 

Software hinges on the cooperation of execs. The most durable software solutions cross silos like finance, production, sales and marketing. This is easier said than done because traditionally, IT belonged to finance since it was regarded as a supporting function. Now, software is decisive for your competitiveness, so this, naturally, has to change. 

Due to software’s immaterial nature there is necessity to invent a new language for every new concept within. Otherwise, you couldn’t communicate among the developers as well as with the businesspeople. But there is a fine line between keeping this new language intuitive and straightforward and marketing nonsense. Thus, don’t hesitate to ask when you don’t understand it. And don’t pay for anything you don’t understand even if it takes a little longer.

Software deployment is more important than software development. People are used to software projects being late. This is because people don’t pay enough attention to the so-called endgame process; i.e. releasing and deploying (and maintaining) the built software; which can easily take months in itself. Hence to ensure the necessary quality you need to think backwards; i.e. starting with the intended time-to-market date; rather than working your way forward.

Software security is a hot potato which demands continuous effort. First of all, let’s not forget that it starts with people being conscious about their behaviour. Technically it is an ongoing race between securers and intruders. Unfortunately, this makes it an intriguing candidate for deliberately slowing down things. Whenever you are sensing something like this ask twice.

Imperatives

Software ensures your competitiveness. Soon you will, again, have more software- than hardware developers. Better you get prepared for it because it takes longer than you expect; easily multiple years (don’t forget that it took Google “only” 20 years to get their search engine right). For this time, it wouldn’t hurt to steal the one or the other seasoned software executive from the software industry.

Naturally, this list is not conclusive. But maybe it can serve as a starting point for the unavoidable; 

Sooner than later you will have more software than hardware developers (in the car industry software has already reached this status). 

  [1] Specification by example (SBE) is a collaborative approach to defining requirements and business-oriented functional tests for software products based on capturing and illustrating requirements using realistic examples instead of abstract statements. It is applied in the context of agile software development methods, in particular behavior-driven development. This approach is particularly successful for managing requirements and functional tests on large-scale projects of significant domain and organizational complexity.(https://en.wikipedia.org/wiki/Specification_by_example)  

[2] Code refactoring is the process of restructuring existing computer code—changing the factoring—without changing its external behavior. Refactoring is intended to improve nonfunctional attributes of the software. Advantages include improved code readability and reduced complexity; these can improve source-code maintainability and create a more expressive internal architecture or object model to improve extensibility.

(https://en.wikipedia.org/wiki/Code_refactoring) 

[3] Technical debt (also known as design debt or code debt, but can be also related to other technical endeavours) is a concept in software development that reflects the implied cost of additional rework caused by choosing an easy (limited) solution now instead of using a better approach that would take longer.(https://en.wikipedia.org/wiki/Technical_debt)