Category Archives: On Product Management

In my many years doing product management or managing the function, the number one blocker to getting the features I want (and the user needs) is……software architecture.

Reading Mike Driscoll’s recent blog on software craftspeople reminded me that this architecture topic has been stewing in my brain for a while now.  Time to write about it.

“Too hard”, “too complex”, “too long” are the persistent reasons behind engineers’ resistance to feature requests or major product pivots.  What I realized is that in every case, it was the software architecture holding us back.  More specifically, the lack of componentization and modularity.

And the pattern spans every experience I’ve had; across lots of different products, across lots of different market sectors, across lots of different architectures (from client-side tools to client/server apps to SaaS/cloud apps), and across lots of different company sizes (pre-revenue to behemoths like SAP and EMC).

Need a new UI presentation tier?  Sorry, that code is co-mingled with the underlying business logic.  Need a new data management tier?  Sorry, the file system is bound to the rest of the code.  Need new business objects to show up in the schema?  Sorry, we can’t split our giant table and it’s already too big to extend.

One can understand how this predicament arose.  When new products are built, what’s required is focus on solving the user problem at hand.  You don’t have time nor money to design for unknown needs and future flexibility.  So why pay for abstraction and modularity without any present-day reason?

The bigger problem is when products mature and the user needs outgrow or diverge from the capabilities of the original architecture.  What to do next?  Re-factor and modularize?  Re-build from scratch?  Limp along by stuffing new features into the code but with huge effort each time?

Nobody knows the magic formula for how to make these decisions.  Re-factoring scares the crap out of engineers lest they “break something”.  After all, by the time this discussion arises, you’ve got spaghetti for code.  And the folks who wrote it might not be around anymore.

Re-write scares the crap out of the business leaders, since it appears to be paying twice for the same product.  And there’s the inherent risk of missing deadlines.  Oh yeah, and you just put your legacy product version on life support so you can afford to staff the engineers on the re-write project.  And you’re losing ground to competitors along the way, since you’ve stopped new feature development to pay for a better architecture.

No wonder products whose architecture devolved to something bad, or started that way, never get fixed.

This vicious cycle is what creates the opportunity for “innovation” in the form of a start-up who has the benefit of a clean sheet of paper: fresh, elegant code using state-of-the art languages, components and tools.  That seems like a wasteful way to solve the problem.

Enter the architect.  If you have a great architect, every problem is reduced in magnitude.

With a great architect, new products have some modularity and flexibility designed in.  A little bit of future-proofing goes a long way. Existing products can be selectively modularized and modernized so the new functional capabilities are delivered without breakage.  And if the time comes for a re-write, you have confidence that all of the lessons learned from the legacy code base are applied to the new design.  Thus, a greater chance of success, especially in meeting a deadline.

So, what makes a great architect?  In many respects, a lot of the same characteristics that make a great product manager: curiosity, an ability to translate what users and salespeople need into technical terms, abstract thinking that enables one to imagine new possibilities, etc.  Of course, the architect also needs the deep technical experience too.

Back to the premise of Mike Driscoll’s article: the best software is being built by people with, dare I say it, experience.  Experience to avoid pitfalls because she messed something up before.  Experience to choose the right tools for the job, much like a fine craftsman that builds furniture, or houses, or bespoke clothing. Experience to know what degree of flexibility to design in, without paying for needless flexibility that feels more like insurance against every conceivable future requirement.

I’ve known some good architects and probably only one or two great ones.  With the great ones, we have had some huge debates thanks to the force of personality that seems to come with great ones.  But in the end, despite the strong personalities, great architects are worth having.  And the great product companies know this, which is why they spend a lot of money on great architects.

I say it’s money well spent.

We recently hired a bright, talented young woman into my organization as a product manager.  She had interviewed with members of both my staff and that of colleagues by the time she met with me.

The people in my staff and peer departments are almost entirely comprised of males.  I asked her whether she sensed any chauvinism during the round of interviews.  To which her response was, “no”.

Later, I felt regret for asking the question.  Whereas I was asking in part to establish empathy (as in, “I’m not a chauvinist and won’t abide it in my team”), I realized the dilemma I could have exposed her to.

In effect, she could only say “no” because if she said “yes, I sensed chauvinism” then she could think I had a reason not to hire her on the basis of fit or avoidance of future conflict.

On further reflection, I realized I asked the question because my own ability to assess the situation is limited.  Limited by a cultural gap between me and the primarily Czech workforce she would be working with.  In other words, I don’t know what chauvinism is, or is not, in the Czech culture.

In the year I have been here, there have been times where I felt that I was able to sense cultural differences.  This situation reminded me that there are many things I don’t (yet) understand.  And that my cultural norms can’t simply be projected onto another culture.  Disconcerting….

Let the learning continue.

If I hear this question in a high tech company again, I’m going to puke.  For starters, because your/my company doesn’t have Steve Jobs.  He’s a freak of nature.  A genius of sorts.  And one of a tiny number of people in the history of the technology industry that have his skills.

But lots of companies make great products and lots of money without needing a Steve Jobs.   Shouldn’t we focus on that instead?

First, let’s stop doing the things that are sure to deliver a bad product.  That should raise the chances of success by 50%.  Such as: catering to a small percentage of a user base with esoteric features that will appear complicated to the rest.  Or, rushing to deliver something without proving it’s useful and useable.

Then, let’s do the things that look like best practice. Spend the time upfront designing it right.   Explore contrarian approaches and avoid mimicking competitors without knowing exactly why.

Sweating the details.  Avoid making the user’s life too complicated with extraneous features.  Wait a minute, isn’t this what Apple does so well? 

I’m a deep skeptic of “absolutism”.  And the use of “engineering” to describe software development breeds absolutism.

The word Engineering in other contexts is grounded in science.  As if there is one answer, or at least one best answer, to a scientific problem.  For example, mechanical engineering is bound by properties of the materials in use.

Whereas software development is about the art, not science, of using languages. While languages have rules, they also have flexibility.  Use of a language can be precise, obtuse and everything in between.

Lots of priorities can be served (or not) with a given program.  Want your code to be performant?  Want your code to be maintainable, as in understandable by others?  Want your code to be modular so that it can be easily refactored or replaced?  All will affect how the code is written.

If you doubt the flexibility of coding languages, then what can explain software quality assurance?  After all, these myriads of tests are to deal with the innate diversity, flexibility and expressiveness of code and of the coder.

And we haven’t even got to the choices in designing components of code and architectures.

So why does this matter?  Because thinking about software development in – pardon the word – binary terms ignores many of the choices and challenges of building great software products.  You might not care about things like “cyclomatic complexity”, but you will when you inherit someone else’s code from 10 years ago and you need to keep it going.

We need to focus on choices not absolutes; on degrees of truths.  Software has gotten too damned complicated to think of it in simplistic terms.

Maybe we should call developers “software linguists”?