It’s impossible for a large organization to operate as efficiently as a tiny one but I also don’t really believe the article’s implied claim that “a couple smart guys” could solve essentially any given problem to clients’ satisfaction within a reasonable timeframe.
Imaginary problems are the root of bad software
231–240 of 511 posts
Re: Imaginary problems are the root of bad software
#232Great advice, spot on At work we have this terrible “Enterprise Architecture” team comprising of highly paid people who haven’t written a single line of code and who don’t know the intricacies of our business but keep proposing complicated “Event Driven Architectures” and “Micro this and Micro that” and just reciting the latest buzz words just to keep appearing cool. It’s insane how much total cost they add to the or…
I consult as a software architect and my job is mostly the opposite of this: asking people what problem they are trying to solve and why they haven't considered $EXISTING_SOLUTION
Re: Imaginary problems are the root of bad software
#233The author hits the nail on the head with his claim that imaginary problems are more fun than real ones. As developers and smart folks in general, we like complicated problems that are big and far away. How many times have I heard in a meeting, "Yeah, but when we have 1M users..." It's great fun to think your product will get to 1M users. It's also very unlikely. It's not nearly as fun to finish and ship and market a…
I remember having a similar argument with someone saying that your C code has to compile and work on every platform that exists, including weird CPUs with known bugs. Unless you're working on something like the Linux kernel, that's an imaginary problem.
"Newer versions of the compiler build your code with security vulnerabilities" is a very real problem in C. E.g. since x86_64 has no aligned memory access instructions, a lot of programmers assume there's nothing wrong with doing unaligned memory accesses, but actually recent gcc/clang will happily compile those into RCE vulnerabilities.
Re: Imaginary problems are the root of bad software
#234How do you manage boring part though? Going mad because of boredom is a real thing. I definitely agree that some of my job is caused exclusively by my need to keep myself entertained. But what's the solution? Another factor is resume driven development. Yes, you can frown upon it all the day, but in the end I'll switch company and I'll need to find a new job. And, like it or not, but everyone these days wants a lot o…
i think it's important to acknowledge when you're working and when you're playing. working on fun things isn't inherently bad, and can lead to actual productivity when the things you learn during your fun geeky tangents turn out to be useful to the actual work.
but if you start convincing yourself that the fun distraction is the actual work you need to be getting done, then you might have a problem. (not to say that actual work can't be fun too. jut saying make sure you know which is which)
Re: Imaginary problems are the root of bad software
#235Earlier quoted context omitted.
"real architects" write code and simply hop from one team to the other so that they have a reasonable picture of the overall system and can try to guide all the teams to make harmonious choices and possibly even reach some goal. This still results in a lot of compromises and problems. Anyhow they should be there talking to the developers in a 2-way fashion so that then end result is not entirely "from on high".
I haven't ever seen one of them. IME architects tend to be people who tell your team that you should be using Azure Cosmos after a Microsoft salesman takes them out to lunch. They last coded 5 years ago.
They exist - I am one - but it doesn't work unless your leadership wants someone who doesn't fit in existing hierarchies. I tend to consult and if I go somewhere where I have prior relationships with leadership, it works. If not, I get treated as part of someone's narrow reporting chain and all the incentives are wrong.
Re: Imaginary problems are the root of bad software
#236This had good points up until the point where it conflated banking software with ‘moving a few numbers around’.
There are vast differences between the pathologies that affect small scale contract web app development as detailed at the start of the article, and those that affect global enterprise development such as is required to build large scale online banking systems. The biggest difference being that many of the things which are ‘imaginary problems’ for the small time web app are very much ‘real problems’ for a publicly traded company with responsibilities to several government regulatory agencies.
And sure, these institutions are just as prone to conjuring imaginary requirements, but it requires considerably more sophistication to tell the difference between ‘something someone in the German compliance office dreamed up to make themselves seem important’ and ‘something that if we get it wrong will result in billion euro fines’ when you’re building a banking system rather than a podcast website.
Re: Imaginary problems are the root of bad software
#237Earlier quoted context omitted.
What kind of software do you work on? At what company? I have seen low level parts that are managed well, because employees have skin in the game But I’ve also seen a lot of what this post is talking about
Until you have the star developer that starts promising the product manager he can do all the extra features in a week. And then of course none of them actually work decently or at all. But at that point it must be maintained by the whole team anyway.
Well yes, but I have veto power for that reason, as lead engineer.
I am the lead because I know, from experience, not to allow this kind of nonsense to happen.
Re: Imaginary problems are the root of bad software
#238If anything it's the incentive system in software industry, which is at fault. 1. No designer is given promotion for sticking to conventional designs. It's their creative & clever designs that get them attention and career incentives. 2. No engineer is paid extra for keeping the codebase without growing too much. It's re-writes and the effort he puts in to churn out more solutions (than there are problems) that offer…
I agree with just about everything you've said, except that bit about rewrites. Rewrite projects typically go down in flames, and on the rare occasions that they don't, the business stakeholders are still mad because their precious feature factory was down for maintenance for months.
I don't think you two disagree, GP is just saying that large-scale rewrites are rewarded, regardless of the result. I've seen that happening even when stakeholders were unsatisfied.
Re: Imaginary problems are the root of bad software
#239Earlier quoted context omitted.
What kind of software do you work on? At what company? I have seen low level parts that are managed well, because employees have skin in the game But I’ve also seen a lot of what this post is talking about
I'm in the same boat as GP. I work in finance. CTO said he wanted to keep things simple and stable, so I do it. It is only possible because I'm a technical manager myself and I have a very competent (and technical) product manager working with me. But for every person like me, there are 10 other devs trying to cram every pattern from the GoF book in their corner of the codebase, so I have to spend my scarce time revi…
Am GP, it is finance based, but not commercial finance.
Most of the systems handle complex calculations. The system is a monolith that has been around for 15 years or so.
It isn't cool. It isn't pretty. Lots of it would be better for a refactor, but absolute stability is the goal. Refactoring things may result in long-term cost savings, but with risk. The business has no risk appetite, so it doesn't make sense. If it works, it stays, however ugly and costly.
That isn't to say some things don't get refactored, but there's a strict business case that needs to be met. Usually if the system is under performing, error-prone or end-users want features/performance that can't be accommodated without a refactor.
It's nice. The latest framework isn't being integrated year after year, there's no microservices, nothing fancy.
It's java. It's tested. It works. It makes money. It pays.
Re: Imaginary problems are the root of bad software
#240It might be more general than that: imaginary problems are at the root of bad___
Where ___ could be something produced like software (or furniture, etc.), or theorised such as scientific theorems (as even though thought experiments are useful, if we don’t go beyond them, we are often lead to bad science), etc.