5 Biggest Problems in Software Development [22/100]

Software development is not particularly easy. Like any complex business, it has a bunch of the most difficult areas in which most people are quite helpless (although many pretend they aren’t).

Disclaimer: this text isn’t profound or something, simply because after six hours of meetups, it’s simply impossible to write anything more serious than a football chant. So it’s all relatable nagging about software development and product management, no solutions here.

5. How to measure user satisfaction?

So at a software development company, we work our asses off, write programs for people to use. And we have not the slightest idea how satisfied these people are with our software! How well does our product solve user’s problems? Of how many years of life did we rob the user by loading that dialog box five seconds instead of one? How many neurons were destroyed when we had some downtime? How much positive emotion did we stimulate by adding emojis to the navigation menu? Actually, do users love our product or hate it?

Unfortunately, no one yet can answer these questions for a software engineer. Some try to use Net Promoter Score, but its effectiveness is pretty mediocre. When we ask users, “How likely are you to recommend Targetprocess to a friend or colleague, on a scale from 1 to 10?” people naturally answer, “WTF? I don’t discuss this stuff with my friends!”

Are there other ways for software engineering to understand customer satisfaction? Users tend to ignore serious, profound questions about a software solution. If a handful of them even respond, it only creates a wrong sample. You can’t draw any conclusions from it. You can get a more or less normal image of user satisfaction by conducting a serious sociological study. But what team has time for this? Who’s got the resources?

By the way, what if you work in outsourcing or custom software development? How often do you get user feedback about the software you’ve made? Do you know whether they’re happy with what you build?

Philosophical question here: how do we, people in a software development team, live without knowing we benefit someone?

4. How to split big software development tasks?

Almost any developer strives to take up a large task and deal with it without breaking it down into smaller tasks. Which is understandable, because small tasks in software projects have higher transaction cost. Each of them needs to be launched, go through testing, be reviewed, released into production. So wouldn’t it be great for a software developer to just work peacefully on one big chunk of work for a whole month? No, it wouldn’t! There are, for sure, complex tasks in the software development process that require tremendous focus and extended deadlines, but these are rare. Experience shows that it’s better to fragmentize the work for a programmer.

Almost anyone would tell you that. However, in real life, implementing this practice turns out to be a common problem. It seems that as humans, we simply can’t get into this habit, no matter how hyped we are about agile software development. Accordingly, the practice of splitting work in smaller chunks degrades as soon as we get distracted.

3. How to avoid rewriting the system every few years?

Any product that survives the first couple of years will be rewritten. It’s just the fucking law of product development. We’ve once rewritten Targetprocess completely and subsequently rewritten half of it (and it’s a pity that we haven’t rewrite the second half back then). The book Coders at Work is full of stories about rewriting products. Apparently, it’s impossible to get things done well on the first try.

It kinda makes sense, though. The first version of a web application (or whatever product) is usually written really quickly to test the hypothesis and the market. At that stage, most of us think: why invest in perfect code and architecture if the system might turn out to be a waste? Let’s first see if it’s needed—and if it is, we’ll make it cool. Unfortunately, it never works out as planned. The second system effect catches up with you, after which either the product dies or rises like a phoenix—through the third rewriting only.

Well, every couple of years, some revolutionary brings a rocking new technology to the market. And it will sooner or later force your team to the fourth rewrite.

Evolutionary architectures stay beyond our reach.

2. How to estimate workloads (at least 80% accuracy, pls)?

Now, this is traditionally a major challenge for a project team. Therefore, managers spin and sneak around, come up with rules for multiplying by two, play estimation games with developers, and don’t trust anyone at all.

Obviously, it is possible to achieve acceptable accuracy of estimations, but only at the cost of unacceptable time investments. Few people understand this, and thus they require it to be done in about 10 minutes (I am no exception here!). At best, they give a day. Ideally, you’ll get two days to decide.

You can obtain decent accuracy if about 10% of the time of the entire project is allocated for the workload estimation. But if you tell this to any manager, they’ll think you’re bananas and turn to other developers for a “10 minutes estimate”.

1. How to prioritize features?

To me, this is one of the biggest problems in software development. The absolute #1! In fact, if you do what you need to do, it’s good enough even if the quality of your work is mediocre. But if you do things altogether useless, that’s the worst (well, the worst is to sabotage work at all, but hopefully nobody does that).

Which features in a product are more important and which are less important? How many products are dead now only because of the wrong decisions of product managers? How many millions of productive hours were spent on useless shit? Let’s leave these rhetorical questions unanswered.

We’re trying to use some simple models (Kano), some quirky models (WSJF), and some linear models with coefficients. All of this works rather poorly and in terms of quality can only beat (or not) the intuition of an experienced product manager.

Sadly, at this stage of the industry’s development, we’re all forced to trust the black box in PO’s head. Because it’s impossible to look into it, it’s also impossible to explain any damn thing, and you have to convince yourself first, then everyone around you that your intuition has produced the correct roadmap for the next quarter.

We have some ideas how to prioritize features better using networks, but no tools support it yet.

Well, it is what it is, I guess. 🤷‍