Data Structures vs. Functions in the Age of Microservices

The old wisdom of “data structures over functions” has stood the test of time for probably 50 years now. It states that long-term, a system is better built on sound data structures than functions. While functions may hide clumsy data structures for a while, when faced with evolution and new user needs, poor data structures will come back to haunt you and will eventually bring down the system.

Continue reading “Data Structures vs. Functions in the Age of Microservices”

Why I Don’t Teach a Traditional Software Architecture Course (Any Longer)

tl;dr The software development contexts that I deal most with these days are open source projects and fast-moving startups; both don’t seem to have much use for what is traditionally taught in software architectures courses.

Let me start by saying that I love a good software architecture as well as software architecture in general. My dissertation was on better modeling object-oriented frameworks and I have played the architect role for most of my engineering days. I even started a traditional software architecture course at my university. However, I got bored quickly and couldn’t connect it to the practice I dealt with, so I passed the course on to a colleague who is now teaching it. I do teach, however, the associated software architecture project, in which student teams perform some analysis and provide recommendations on a real-world architecture provided by an industry partner.

Continue reading “Why I Don’t Teach a Traditional Software Architecture Course (Any Longer)”

What’s Wrong in Software Product Line Engineering? The Separation of the Platform as a Cost Center from the Product Units as Profit Centers

In three previous posts I had reported about our research into problems with product line engineering. Three important specific problems (of several more) were:

  1. Lack of resources in the platform organizational unit
  2. Insufficient collaboration between product and platform unit
  3. Political power play between product units

Continue reading “What’s Wrong in Software Product Line Engineering? The Separation of the Platform as a Cost Center from the Product Units as Profit Centers”

What’s Wrong in Software Product Line Engineering? Political Power Play Between Product Units

In previous blog posts we identified

as causes for problems in software product line engineering. Of several more, I want to pick a third and final one, before we turn to the root cause of it all in the next blog post. This third cause is the political power play between product units as they try to prioritize requirements for the platform organization.

Continue reading “What’s Wrong in Software Product Line Engineering? Political Power Play Between Product Units”

What’s Wrong in Software Product Line Engineering? Insufficient Collaboration between Product and Platform Unit

As previously posted, we analyzed current problems in product line engineering. One case study was a healthcare software product line, one was a business software product line, and one was a telco carrier software product line. All developers in their respective product line were homogeneous in time and culture (one main location, one social culture), that is, we had no problems of globally distributed software development. This both made the analyses easier but also limits the generalizability of our conclusions.

We presented our analysis using cause-and-effect chain diagrams. The following figures shows an excerpt of these diagrams.

Continue reading “What’s Wrong in Software Product Line Engineering? Insufficient Collaboration between Product and Platform Unit”

What’s Wrong in Software Product Line Engineering? Lack of Resources in the Platform Organizational Unit

A few years ago we analysed several highly successful software product lines. You can find the details in our corresponding publication. We had been brought in, because the business owners of each product line felt that something was amiss and that productivity could still be improved. In this short blog post series I’ll discuss the problems we found and what to do about it.

Continue reading “What’s Wrong in Software Product Line Engineering? Lack of Resources in the Platform Organizational Unit”

There is no Product Owner

One of the most difficult aspects of Scrum is the role of the product owner. Most software vendors have a product management function, typically split into strategic and technical product management. Technical product management is usually equated with Scrum’s product owner role, that is, the guy or gal who writes business-value-oriented user stories and epics, grooms the product backlog, and then some. This is separate from breaking down business-oriented features into technical tasks, which is left to the engineering team.

The problem: A person who can do this well is hard to find. It is easy, though, to find someone who believes they can be a good product owner. In practice, most successful software vendors I have seen have a business-oriented strategic product manager for a given product or major component, and have a senior engineer play the product owner role, reaching all the way into product development, that is, not only writing users stories but also breaking them down into tasks.

I’m a strong believer in product management. It is the most critical function in product development. It took me many years to accept that good Scrum product owners cannot be groomed from MBA or other business-oriented degree programs. Almost always will you need someone with a technical background to fill that role or it will go off the rails. However, there are really few people who’d like to take on that job; they’d rather be programming. Therefore, you’ll have to ask a senior engineer or other engineering leader to collaborate with the strategic product manager and turn the roadmap into features that can go into a product backlog.

So, as I said there rarely is a (stand-alone) Scrum product owner; usually it is a senior engineer adding to their busy schedule to make things work out.

Agile Feature Teams vs. Inner Source

Agile methods reacquainted developers with the idea of working from business value rather than focusing on technical concerns only. Agile methods are therefore often equated with feature-driven development, in which work is driven by features prioritized by business value irrespective of technical consequences. This thinking can create code silos and wreak havoc on software architecture and component quality. Developer complaints are legion, in particular for never getting the time to fix things or do them right in the first place.

Continue reading “Agile Feature Teams vs. Inner Source”