To be fair to this example it was also an tough situation: imagine MS trying to release W10 Classic with W11 still in prod!
E.g. the older ver may well be better, and even what most users want, but pulling off the optics of selling both without damaging the modern variant is difficult if you're not c-level. The internal champion would basically be ending their career with "yeah I messed up the product let's roll back". Also sends a very interesting signal to shareholders and competitors about the direction of the corp.
>Sure but games are entertainment, not software, if we're being pedantic.
>You can't really map b2b enterprise software tropes onto b2c entertainment products, as ActiBlizz would discover.
you appear to be another person who decided to stop reading my comment before reaching the last paragraph.
its only 3 sentences long, so i cant really condense it much more, but here is a copy/paste from another comment i made that is formatted extremely clearly for my two points:
"[...] sometimes users want something. that something might be a feature request, or it might be a feature removal. [...]
a) ignoring your users requests can sometimes be a bad choice.
b) you might not necessarily understand every underlying problem that every user has. worse, you might think you understand the problem when you dont."
It will be interesting as orgs flatten to see what will keep all the remaining "superhuman AI-powered all-in-one" employees from just making their own shop.
In the future, prostitutes no longer work the street corner and you no longer roll up. No no, prostitutes vibe code apps nobody asks for with subtle hints in it that they're offering their services. Then, clients buy it as a proxy.
I don't see this happening. Even today, I can place a bet on a prediction market that nobody women will give me a blow job tonight, a lady of the night then places a counter bet wagering that I will, and shows up at my house.
Services in individual apps are a thing of the past.
Good lord, thank you. I'm a huge fan of LLMs, they've replaced enormous amounts of toil for me but they are not 'my job'.
If you walk to the kitchen and fry up an egg are you now a master chef? What's the difference between a surgeon and a butcher ...they both cut things?
Most shops never really needed development expertise in-house as there's no shortage of many decent tools equally suitable as code for getting machines to do most business things.
In some ways this is worse because while it's functionally the same black box intermediary as the alternative-to-code tools there's an illusion of control and more sunk cost. Do you want your sales team selling or learning JavaScript churning out goofy knock-offs for a well-solved problem?
Aye, it never happens but it does sell a lot of books ;)
I don't think we'll reach this promised land™ until incentives re-align. Treating software as an assembly line was obviously The Wrong Thing judging by the results - problem is how can we ever move to a model that rewards quality perhaps similar to (book) authors and royalties?
Owner-operator SaaS is about as close as you can get but limits you to web and web-adjacent.
Get couple shredded guys and gals to show off how fit they are so everyone feels guilty they are snacking past 8PM.
Sell another batch of “how to do pushups” followed by “how to do pushups vol.2” with “pushup pro this time even better”.
Where in the end normal people are not getting paid for getting shredded, they get paid for doing their stuff.
I just constantly feel like I am not a proper dev because I mostly skip unit tests - but on the other hand I built last 15 years couple of systems that worked and were bringing in value.
You could switch into a domain where safety-critical software is developed. Here devs complain about the inverse problem: Why are we required to have 100% test coverage?!
(The answer btw: Because nobody would be able to explain to a jury/judge that 80% or whatever is enough)
Or they complain that they know everything has gone to hell but if they blow the whistle revenge will be taken against them.
Everybody who worked with the 2005 Toyota Camry ETCS would have known what was up when it killed a few people, for example. Nobody can work on spaghetti code of that magnitude and not realize that something is off.
Boeing employees who tried to blow the whistle were similarly ignored or silenced while a few died in mysterious circumstances.
Why would you skip unit tests? Especially in the AI age. You can quickly verify your behavior. Also, by not writing them you're also missing out on opportunities to modularize your code.
Obviously, this assumes you write enterprise grade code. YMMV
You can write modular code without writing tests - I write testable code - I don't write tests. When I need I can always add them back, but I tend to skip it as mostly it doesn't make sense.
But still cottage industry of "clean code" is pushing me into self doubts and shame.
I’m a mechanical engineer, not a software person, but I write a lot of (hopefully close to professional quality) code for my work. writing tests while in the beginning/middle of my development cycle has been the best change I’ve made in how I do things in quite a long time. Since I’m a self-taught amateur often working solo, its invaluable for helping me gain confidence that everything I’m doing is working correctly as I learn the language/libraries necessary for me to build each new program.
I’m not saying that you yourself have this attitude - but the “tests are for suckers, I just ship” crowd really grinds my gears because to me it says “ha! Why do you care about getting things right?”
Totally get where you’re coming from though, sometimes the expected behavior is trivial to verify or (in the case of GUIs) can be very difficult and not worth the effort to implement.
Code is a technical specification and could be any programming language, markup, terraform files, configuration, whatever.
Product Spec is written in English and in a such way that everybody can understand it without technical knowledge. Because it doesn't operate in C arrays and nuances of how queues work -- just common sense and real-life objects/entities! Then the actual code is an abstraction that takes the spec and implements it for certain architecture / scalability requirements and so on.
For example you can ask to make to-do list app. You can build it on:
- As a CLI tool
- As a UI web interface
- As an AI agent that operates entirely on voice recognition and text-to-speech as interface
A product spec can omit this "tiny" detail, code -- cannot.
Even if you specify this is Web UI to-do app in product spec, there are still tons of things to choose for developer:
You wouldn't specify in a Product spec that to-do items has to go to an SQS queue that lambda picks up and adds them to a DB, would you? That has to be a separate technical spec document, which is simply called documentation (+actual code in the repositories).
