So, I worked with this one guy who then was promoted to become the product manager. His code "worked" in the way you describe. I.e. it didn't really work, but it worked enough for him to move on to the next glorious moment in his career.
And, yeah, people will recommend him to their employers if those ask. He has a good track record of having "things done". People recommend him because he knows people, not because he's a good programmer.
It's not just that one guy, it's kind of a personality profile that for some reason lacks the drive to make good things. Not in so major way how psychopaths lack empathy, but I think about it in the same way as being a personality problem, not any kind of strategic decision. It's normal for humans to want to do their job well. Regardless of financial situation or other "practical" concerns. It's a value into itself.
Back to that one guy. So, in his head, he generated great value for the company by designing external interfaces. He believed that his contribution was in making the interface to the product easy because his theory of how other people behaved was based on his own behavior: he didn't like to work hard to understand whatever he was doing, he just wanted to see a result on the most basic good-path test to declare his work complete.
I really hated to work with him because I felt like I have to mop up after a drunk teenager party every time he added more glorious contributions to the code base and was happy to see him promoted into management until I realized how much of a bad deal it was. From just being bad code that needed fixing this became bad design that had, well, no real way of fixing.
Just to give you an example: the product was meant to have HTTP interface to its internal state. Some operations could take a very long time, so there's no way around it -- it had to be asynchronous. The subject of this comment designed the interface in such a way that polling for the state change wasn't in any way tied to the request that asked for the state change. This means that in rare cases, should there be an error while two clients are accessing the API one could see the success response to the request made by the other and stop polling, while the error would've been lost.
Of course, errors are rare, and races involving errors are exceedingly rare, so even to reproduce such a condition in a test wasn't a trivial task. Also, the whole idea that the "simple and user-friendly" interface design must change because some grumpy dude showed that in some rare cases it doesn't work didn't sit well with the author of the interface.
The problem is... this product is a distributed block storage system. It has to be extremely reliable in order to be successful. I couldn't imagine anyone would deliberately ignore an obvious design error in a system like that, but when that happened, I lost confidence and interest in the product and left the project in a matter of months. Of course, no one is indispensable, but the project lost a senior programmer in a niche field who dedicated many years to working on the project. Realistically, no matter how good my replacement was, they'd have to spend upwards of a year to just bring them up to speed on whatever I was doing. To the best of my knowledge, they never did. Eventually, they stripped the project down to parts, threw away some, repurposed some others, let most of the core team go and rebranded it as something else.
I blame that one guy for the failure of otherwise interesting and potentially useful thing.
> Of course, errors are rare, and races involving errors are exceedingly rare, so even to reproduce such a condition in a test wasn't a trivial task.
Are you assuming he did this maliciously? He very well may have, but why isn't this just a bug, that any one of us might write? You seem to feel like you understand the field a lot, and perhaps you do - in that case, perhaps, he didn't?
Maybe he did "suck"! But I honestly can't tell from the information you've given me. It sounds like both you and him would not easily write a test to catch the error.
As in to sabotage the company he worked for? -- No. Did he know that he's making a worse program? -- Well, in a way... but, not really. He was really convinced of his own brilliance because he thought he designed a good interface, but he didn't realize that his entire approach to design was bad. He just thought himself genius and that's why he believed that he can easily complete a difficult task. The belief that best is the enemy of the good was a contributing factor. A motivation for him to declare himself a genius by producing mediocre results (albeit at great speed).
> It sounds like both you and him would not easily write a test to catch the error.
I didn't need to write a test to catch the error. I could show in the code how the error may happen. Unfortunately, testing as it is practiced today, has nothing on design errors, it can only aspire to validate implementation. According to some common practices testers are even forbidden from participating in designing software.
> He was really convinced of his own brilliance because he thought he designed a good interface, but he didn't realize that his entire approach to design was bad.
I see, so you evaluated his design and the skills you have allowed you to see it was bad, when he could not?
You are making it sound as if there was something special about my persona in this situation. Well, there was nothing special about "my skills". Anyone diligently following due process would've come to the same conclusion.
Another problem with this situation is that it went nowhere. The project disintegrated for unrelated reasons. So, there's no proof it would've been actually bad.
But, like I said, this is not an isolated incident. I have a better example of bad design created for the very same reasons (but, by a different person) that did and still does have negative consequences for the product. Bonus: making a test that shows the design is bad is extremely costly (basically, unrealistic).
A little bit of history first. A complex computer cluster management software was created without any plans for how to upgrade it. Traditionally, and very often still it's distributed to air-gaped systems, so it's not, and will never be provided as a service. Typically, such software manages anywhere from couple hundreds to tens and in some extreme cases hundreds of thousands of compute nodes, switches, storage nodes etc.
Eventually, the company realized they need some automated way to perform upgrades. Their first effort was to design a procedure for in-place upgrades. Customers rebelled. Not only does an in-place upgrade guarantee down-time, due to the complex nature of the software, usually (or, most likely, always), upgrades didn't go smoothly and required engaging the technical support with days or even weeks worth of email back-and-forth and potential loss of data.
This is when the company realized it needed a procedure for upgrading "in parallel". And here they came up with an idea of reusing existing code for in-place upgrades: they'd clone the management elements of the cluster, upgrade those, and then transfer the rest of the cluster under new management.
They saw it as a win. I saw it as an absolute disaster. My experience with the in-place upgrade was that it would typically leave behind a lot of shreds of the old system. Unused configuration files, or, sometimes, entire databases with confusing names would be left behind. Patched configuration would often end up having features no longer supported by the new system. If the old system lacked validation for some inputs, then new, improved validation procedures would either skip entirely over old data, or struggle with its indirect usage.
Finally, this management software had a lot of third-party integrations with popular tools. Upgrading it in-place often times made it impossible to upgrade both at the same time (eg. upgrading storage engine like Ceph while also using this storage engine to store management configuration). Every such bootstrapping required very convoluted and impossible to test code. In many cases customer would be told to simply remove the integration prior to upgrade and re-configure it afterwards. Of course in case s.a. integration with Kubernetes, this meant customer would lose data (in the form of container state that cannot be reliably serialized and saved somewhere).
To me, the solution was obvious: instead of clone and upgrade in-place, one should install the new system and import the configuration from the old one. This would not allow old stale data, would have to re-validate old input and prompt the user to fix retroactively validation errors. Upgrade and migration of integrations s.a. Ceph or Kubernetes would still be hard, but not as hard as before, as the same principle would apply to them too.
No matter how much I campaigned for my version of design, I couldn't change the situation. The person behind the existing design outranks me. Being higher on the management ladder, it makes them think they know better. They never even tried to estimate the cost the company had paid in providing tech support to a decrepit and poorly built system, or how much development hours had been spent dealing with the bad approach enshrined in bad design, while the same effort could've been applied to development of new features or, at least, to reducing the load on the tech support. I'm sure that to date the company wasted (or lost...) hundreds of thousands of euros or dollars because of the bad design. Probably more: it's hard to estimate the cost of the lost opportunities.
In order for me to prove myself correct, I'd have to build an alternative upgrade procedure. The original effort for this feature had a team of 3-4 developers working on it almost exclusively for at least half a year. Today, the company supports about four dozens of versions of its own product, and the new upgrade system would have to support at least half of that. I will never get funding for such a project, let alone on writing a test that compares the two designs (via their implementations). That'd be many years of work.
----
And the author of this design? -- Well, he's exactly the kind of guy who believes, literally, that the best is the enemy of the good. He works very fast, and often volunteers to help customers directly by adding more untested features to the product. Him being very senior gives him a free pass on code reviews and design documents which are otherwise expected from everyone else. He sees himself a hero, someone who day after day saves the company from devastating consequences of... his earlier bad ideas.
> Anyone diligently following due process would've come to the same conclusion.
> To me, the solution was obvious
> I will never get funding for such a project,
> bad approach enshrined in bad design,
> He works very fast, and often volunteers to help customers directly by adding more untested features to the product.
> He sees himself a hero, someone who day after day saves the company from devastating consequences of... his earlier bad ideas.
What I'm hearing is this guy delivers features to the customers, but your ideas are better, obviously.
If they were obviously better, you'd be able to secure funding to do them. What I think is actually happening is you've been unable to demonstrate the value of your ideas, or convince people they are valuable. The conclusion I am drawing here is that you haven't shown that your way is better - you just believe it is.
My belief is that the attitude that people suck if they write tests that must be ordered, "indicates a lack of understanding that finding the right balance of speed, cost and quality is a compromise." But, many developers believe that their pure code is just always "better".
> What I'm hearing is this guy delivers features to the customers, but your ideas are better, obviously.
Well, then you need to pay more attention... Your interpretation is wrong.
> If they were obviously better, you'd be able to secure funding to do them.
You don't understand the difference between quality and pricing policy. Best food is not the "fast food", even though customers love it and it's cheap. The "fast food" is causing obesity epidemic, diabetes epidemic and a bunch of other health-related issues that, in the grand scheme of things make the savings on the food quality not worth it. But, for some people it's easy to weasel their way out of this problem by pretending that repercussions don't exist, and that they will bear no responsibility for the consequences.
The "deliver features to the customers" guy is the one who internalizes profits and externalizes expenditures. He's a douche canoe. There's nothing positive about people like him. The fact that he gets budget to do idiotic and harmful things is not because they are valuable, but because this creates a condition for a scam that profits those funding him.
In the same way how not everyone is a dietologist and cannot be expected to assess the value of the food they eat, and so has to rely on experts, the customers using our software will not know how well different features of our software are implemented. All they have to go off is a changelog and some promotional materials. There's enough of a time buffer between the customers buying the product and discovering how crappy it is for the product authors to still make profits. And, given the conditions of our market, where the product we make is, basically, without competition, even if the customers discover it's true quality, they'll come back bagging to fix things rather than bail on us. Which gives even more freedom to the "deliverers of features to the customers".
> Well, then you need to pay more attention... Your interpretation is wrong.
> You don't understand the difference between quality and pricing policy. Best food is not the "fast food", even though customers love it and it's cheap.
> There's nothing positive about people like him.
This is the exact problem I'm getting at: Individuals don't get to unilaterally declare what good software is, what the worth of people is, what people do or don't understand.
This guy may in fact have a more nuanced and "better" understanding of software and what goes into making it, than you. Prove that he doesn't! If you can, you can take that proof into work and take his job!
And, yeah, people will recommend him to their employers if those ask. He has a good track record of having "things done". People recommend him because he knows people, not because he's a good programmer.
It's not just that one guy, it's kind of a personality profile that for some reason lacks the drive to make good things. Not in so major way how psychopaths lack empathy, but I think about it in the same way as being a personality problem, not any kind of strategic decision. It's normal for humans to want to do their job well. Regardless of financial situation or other "practical" concerns. It's a value into itself.
Back to that one guy. So, in his head, he generated great value for the company by designing external interfaces. He believed that his contribution was in making the interface to the product easy because his theory of how other people behaved was based on his own behavior: he didn't like to work hard to understand whatever he was doing, he just wanted to see a result on the most basic good-path test to declare his work complete.
I really hated to work with him because I felt like I have to mop up after a drunk teenager party every time he added more glorious contributions to the code base and was happy to see him promoted into management until I realized how much of a bad deal it was. From just being bad code that needed fixing this became bad design that had, well, no real way of fixing.
Just to give you an example: the product was meant to have HTTP interface to its internal state. Some operations could take a very long time, so there's no way around it -- it had to be asynchronous. The subject of this comment designed the interface in such a way that polling for the state change wasn't in any way tied to the request that asked for the state change. This means that in rare cases, should there be an error while two clients are accessing the API one could see the success response to the request made by the other and stop polling, while the error would've been lost.
Of course, errors are rare, and races involving errors are exceedingly rare, so even to reproduce such a condition in a test wasn't a trivial task. Also, the whole idea that the "simple and user-friendly" interface design must change because some grumpy dude showed that in some rare cases it doesn't work didn't sit well with the author of the interface.
The problem is... this product is a distributed block storage system. It has to be extremely reliable in order to be successful. I couldn't imagine anyone would deliberately ignore an obvious design error in a system like that, but when that happened, I lost confidence and interest in the product and left the project in a matter of months. Of course, no one is indispensable, but the project lost a senior programmer in a niche field who dedicated many years to working on the project. Realistically, no matter how good my replacement was, they'd have to spend upwards of a year to just bring them up to speed on whatever I was doing. To the best of my knowledge, they never did. Eventually, they stripped the project down to parts, threw away some, repurposed some others, let most of the core team go and rebranded it as something else.
I blame that one guy for the failure of otherwise interesting and potentially useful thing.