4 ms·
You can only pick two out of the three from the triad of optimization (time, monetary cost, quality). Industry prioritizes functional solutions (requirements)
by screamingninja 3y ago
You can only pick two out of the three from the triad of optimization (time, monetary cost, quality).
Industry prioritizes functional solutions (requirements) over efficiency. If efficiency is one of the requirements, it will be addressed (e.g. video games). Optimizing for efficiency takes additional effort. The article argues that the software industry is stuck with inefficient tools and practices. Engineers can and should do better, aiming for better apps, delivered faster and more reliably with fewer resources. However, economy dictates that as you optimize two variables from the triad, the third will get de-prioritized.
Edit: I can see the downvotes but no idea why. Would you care to explain?
- Clubber 3y ago>I can see the downvotes but no idea why. Would you care to explain? I dunno, but this has been taught in PM since PM. I remember learning it in the 90s and it still holds true. If you want it fast and a large scope, you have to throw bodies and planning at it, costing money. If you want it cheap with a big scope, you have to wait for that small team to finish it (time). If you want it fast and cheap, you have to limit your scope. Time/Cost/Scope, pick 2. Perhaps people are taking issue with quality vs scope, but quality is a part of scope for certain. https://www.projectmanager.com/blog/triple-constraint-project-management-time-scope-cost https://www.projectmanager.com/blog/triple-constraint-projec...
- ajmurmann 3y agoI don't think this can even be blamed on what the industry prioritizes, but on what customers reward. How many users pick one solution over another because it's quicker? Outside of very specific use cases practically never happens. These types of complaints ultimately come down to wanting users to care about different things. It's not dissimilar from complaints about nobody having fashion sense anymore or buying too much processed food.
- atomicnature 3y agoYes, the engineers who verbally bat for efficiency/correctness in these threads have no qualms about practically abandoning efficient sublime to less efficient vscode (in general, of course; not that there aren't exceptions) :)
- _gabe_ 3y ago> How many users pick one solution over another because it's quicker? Isn’t that what drives the most sales in upgrading a phone? Idk many people that care about the microscopic improvements to the camera or UI, most of the time it’s something along the lines of “my iPhone 8 doesn’t run fast enough anymore, time to upgrade”. Same with consoles. I remember one of the big pitches of next gen consoles being “look! No more loading screens!”. And even ChatGPT 3.5 vs ChatGPT 4. There are tons of people that will use crappier output because it’s faster. Speed is still absolutely a selling point, and people do care.
- ajmurmann 3y ago> I remember one of the big pitches of next gen consoles being “look! No more loading screens!”. And even ChatGPT 3.5 vs ChatGPT 4. Those are the very specific use case I mentioned. How many users are gonna swap to a different chat client because of this or a different word processor because it start 1s faster? As a parallel comment points out, even developers swapped away from the very quick Sublime to Atom and now VSCode. At work hiring at some point became a huge pain because we swapped from Greenhouse to the recruiting tools built into Workday. It was super slow. I hated it, our recruiting team hated it, but it was purchased because it checked all the boxes and integrated with all our other stuff in Workday. The comparison to engine efficiency made me think that if we really want faster software, we need the equivalent of a gasoline tax for software, but what's the negative externality we are preventing?
- acdha 3y agoI think you’re right that there’s a fundamental tension between those three factors but it’s begging the question of whether we’re seeing those fundamental limits versus something else. For example, I’ve seen multiple teams deliver apps using React frameworks which have no advantages in any of those points - they’re notably slower than SSR, use more resources on both the clients and servers, and don’t ship noticeably faster because while some functions are easier that’s canceled out by spending enough time on toolchain toil to make a J2EE developer weep. That suggests that while those three factors are part of the explanation they’re not sufficient to explain it alone. My theory would be that we’re imbalanced by the massive ad-tech industry and many companies are optimizing for ad revenue and/or data collection over other factors such as user satisfaction, especially with the effects of consolidation reducing market corrective pressure.
- deleted 3y ago[deleted]
- cmilton 3y agoGreat point! I've always heard "There's good, fast, and cheap. Pick Two."
- gizmo 3y agoHow much programmer time has been wasted by gdbs byzantine UX? In a rational world, would we collectively invest time into building extremely good debuggers? It's a tragedy of the commons, where everybody would benefit from better tooling, everybody wastes time dealing with poor tools, but nobody is willing to put time/effort/money into making better tooling.
- screamingninja 3y agoLike this? https://www.gdbgui.com/ https://www.gdbgui.com/ There's plenty of FOSS developers that work for intrinsic rewards and likely produce better software.
- InsiderTesla 3y ago[dead]
- screamingninja 3y agoHere is some analysis on why these variables are often considered and what else is important. https://www.sciencedirect.com/science/article/abs/pii/S0263786398000696 https://www.sciencedirect.com/science/article/abs/pii/S02637... https://www.researchgate.net/publication/305462896_Project_managament_cost_time_and_quality https://www.researchgate.net/publication/305462896_Project_m... More recent publications replace "quality" with "scope" since quality cannot be controlled directly and is seen as a result.
- InsiderTesla 3y ago[dead]
- ndriscoll 3y agoFrom what I've seen the faster solution is also usually the simplest, which makes it faster to deliver and easier to maintain. We're far away from what Knuth warned about (micro-optimizing assembly). It's more at the level of high-level design, technology choice, etc. Like at my last job, we had something like 50 microservices, Kafka, rabbit, redis, varnish caching, etc. For under 1k external requests/second and some batch processes that ran for a few million accounts. If we cut out all of the architecture to "scale", you could've run the whole thing on a laptop if not a raspberry pi. And then a real server could scale that 100x. The company was looking at moving to a "cloud native" serverless architecture when I left.
- atomicnature 3y agoAgreed. My argument is that software from market/customer perspective is more like a movie, which is supposed to delight them. And industry rightly priorities the capability/delight factor over mere efficiency for efficiency's sake. Only engineers are interested in efficiency for efficiency's sake (also - will the engineers pay for more efficient software? Nope. Why did engineers abandon Sublime for vscode? So when anyone wears a customer hat, they tend to prioritize factors other than efficiency/correctness more unless we are talking about life-saving medical saving devices or such).
- hongsy 3y agoReminded me of this https://en.wikipedia.org/wiki/Impossible_trinity https://en.wikipedia.org/wiki/Impossible_trinity The impossible trinity (also known as the impossible trilemma or the Unholy Trinity) is a concept in international economics and international political economy which states that it is impossible to have all three of the following at the same time: - a fixed foreign exchange rate - free capital movement (absence of capital controls) - an independent monetary policy