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 offers him a chance to climb the ladder.
3. No product manager can put "Made the product more stable and usable" in their resume. It's all the new extra features that they thought out, which will earn them reputation.
4. No manager is rewarded for how lean a team they manage and how they get things done with a tiny & flat team. Managers pride themselves with how many people work under them and how tall in the hierarchy they are.
Our industry thrives on producing more solutions than needed. Efforts are rewarded based on conventional measurements, without thinking through- in what directions were the efforts pointed at.
Unless the incentives of everyone involved are aligned with what's actually needed, we'll continue solving imaginary problems, I guess.
This is a massive change from my first software industry job in 1997.
I was essentially a “design intern who knows HTML” on a team that built a shrinkwrap Windows application for enterprises. The core of the design team was a graphic designer, a cognitive scientist, an industrial designer, and a product manager with industry experience in the customer domain.
The application was Windows native. User research was conducted on site with scientific rigor. Adhering to platform guidelines and conventions was a priority. I think I spent a few weeks redrawing hundreds of toolbar icons so they’d be in line with the Office 97 look (the kind of boring job you give to the junior). If the app stood out on the Windows desktop, that would have been considered problematic.
Today a similar design team would only have a graphic designer and a PM, and neither of them would care the slightest about platform guidelines or customer domain. The UI is primarily an extension of the corporate brand. Hiring a cognitive scientist? Forget about it…
Everything certainly wasn’t perfect in the Windows/Mac desktop golden era. But the rise of the web wiped out a lot of good industry practices too.
Even in Linux there were tools to sync gnome with QT look so you could have one theme applied to every app for nice and consistent look, all the way to how the common icons look.
Nowadays ? Every fucking app gotta have their own different styling. Will the setting icon be three dots, gear, or honey badger ? WHO FUCKING KNOWS. You'd be lucky if you even get a choice between light and dark theme
But hey, we can write same code to work on windows, mac and mobile ! It will work shit in all of them and be slow but we don't care!
THANK YOU!
None of the current SaaS apps I use can come close to the experience of using softwares from that era.
Take a simple list view of a typical Windows/Mac software?
1. Command clicking selected multiple objects
2. Shift clicking selected a range.
3. Right clicking brought up selection actions.
4. Double clicking opened an object.
This pattern was followed in almost list views and there was no re-learning and surprises.
Now can you say the same about the list views of modern web apps?
Can you apply the same list selection experience across Google Drive and Microsoft OneDrive and Apple iCloud? Nope.
That's were we failed as an industry. We let a lot of designers run too wild with their ideas, to put it bluntly.
The indie scene is looking excellent however, a lot of programmers who have already made their money seem to be pushing excellent hobby projects out.
In the former you make money from selling the result, in the latter you make money from selling the hours spent creating the thing.
If the former is unusable it will lead to bad sales. In the latter it might even lead to additional hours sold in change requests.
The former is bought often after evaluation and comparison by the user of the software. The latter is sold to an executive that will never have to use the software as a project.
Now you don't have to. So no one does.
I’m all for craftsmanship, but having four top guys fiddling with design.. it all depends on the domain I guess.
However, a large and insidious cadre of B tier engineers was constantly writing docs proposing meaningless arbitrary system changes and new designs for the sake the changes themselves. These new projects were the only way to get promoted. The entire e4->5->6->7 track was written in such a way that it only ever encouraged “TL”/“architect”types to grow.
This led to constant churn, horrible codebases, and utter bullshit self made problems which could only be solved by digging a deeper hole.
There are companies who handle this well. Ultimately it comes down to engineering culture.
I am. I'm paid more than most developers to run a team doing just this. We make minimal change, have an absolutely non-negotiable focus on stability and minimalism and reject any change that isn't absolutely driven by validated majority user need. Even then, the bar is high.
I'm not saying this is a common situation, but it certainly isn't rare in my experience. Software is a vastly wide scope of software types and requirements. I'm paid to be ruthless, and to know what ruthless looks like in terms of delivering consistently without downtime/data loss/critical issues.
That is to say, there isn't one team doing what you're doing and then another separate team trying to graft new features on all the time, is there? Maybe there is, and maybe that causes issues down the line.
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 can’t imagine a software engineer developing an interest defensive software engineering will be very visible until after there has already been a crisis to screw people’s heads on straight.
A lot of people seem to see “Do things that don’t scale” and think that’s a phrase meant for engineering.
I think your experiences may be skewed by the position you find yourself in?
It was quite telling that after 1.5 years of that project, where all staff had already been replaced once, all they had to show for was a fancy product name and a presentation. And that the manager that led the project for ~2 years left right before or right when it went live - and he did that in a previous project too, where a working .NET backend for ecommerce was replaced with a Scala microservices on AWS system.
I did hear about the latter; I heard they went back to .NET, but the Scala services are still up and running and a maintenance nightmare.
But the lead developer got to play with his favorite tool and landed a job at lightbend because of it. Career-driven development, and I don't even believe he did it for his own career, but for self-gratification. Ecommerce is boring; REST APIs and a front-end are boring. But Scala, distributed systems, AWS, that's all cool and new.
I'm so tired.
I think there are two things to be wary of: 1) Selecting a new technology just because it's hot, and 2) Refusing to consider new technology because the old stuff "just works." A good engineer looks at the requirements and selects the best tool to solve the problem while weighing the costs and benefits. Sometimes that's microservices. Sometimes it's monoliths. Granted, I don't know anything about the developers or business problems at that company, but to say that Scala microservices are just bad without justification doesn't sit right with me. It's all situational.
If an engineer comes to me and asks to use something like Scala, he'd better know all the upsides AND downsides (e.g. effect and streaming abstractions, ease of long-term maintenance, referential transparency, vs learning curve, hire-ability, 100 different ways of doing things, etc).
- There is bias towards rewarding more lines of code or more code commits (which is often the exact opposite of what characterizes good software design).
- There is bias towards rewarding speed of initial implementation (which often goes against medium-term and long term maintainability and ability to handle requirement changes which is usually far more important). The costs of this tends to fall on other developers who come in later and act as scapegoats for the 'apparent 10x developer'.
- The industry keeps dismantling narratives which would otherwise help to reward talent. For example, many companies dismiss the idea of a '10x developer' - Probably because they are aware of the previous point about the fast developer who cuts corners and creates technical debt for others. 10x developers do exist, but they're not what most people expect because paradoxically, they may be slow coders when it comes to LOC metrics and speed of implementation for new features; their code really only shines in the medium and long run and it improves the productivity of their colleagues too so it's hard to properly allocate credit to 10x devs and they only really matter on greenfield projects.
We also get slower with so many people. The coordination overhead is killer and losing context as the product is sliced up into small parts that move on without you
I half-disagree with this. My take is significantly more top-down: senior management has a deficient concept of how product development works. They believe Manpower is to be spent to achieve revenue, either by directly selling the result as a product (e.g. airplanes selling wifi to passengers) or by it being a differentiating feature for the sales department. This causes every allocation decision (like hiring) to fundamentally be biased around getting a tangible return: by creating new projects, new features, and new buggy microservices.
Further, since management only has two knobs (manpower and timeline) to play with, they like to move them to feel like they're optimizing the project. It's always the same fallacies, too: "we hired more people so we can create explosive growth", "we created ambitious timelines, now we're striving to fill them" etc.
I don't have a solution for this, except to note that it can be mitigated by managing up. Construct your own narrative, and take advantage of the fact that the non-technical people above you govern almost entirely by gut feeling.
In retrospect - it was recognized that they built or took good care of money making systems with little drama and that was well appreciated by the companies.
In FAANGs I see now more of "what will get me promoted" versus "what is gonna make the company money" ethos.
FOSS software has vastly different incentives than commercial software, yet suffers from many of the same problems: bugginess, poor performance, lack of documentation, feature misprioritization, bad UI.
That alone indicates that the problem is not merely "misaligned incentives".
Actually, you can reduce most problems down to "misaligned incentives" if you're overly reductive enough. That doesn't mean that it's a useful way to think about the world.
Some other incentives are balanced, though. Persistent low performance or bugginess affects the author and end users equally; the more the author uses their own software, the more this will hurt. Sometimes the low performance is a design trade off; Python isn't Rust, and the users seem to be okay with that. It was done on purpose. Sometimes low performance is a factor of the author's needs; you're trying to run the thing on 1 billion machines, they only have 1; something has got to give. But that's not misaligned incentives so much as it is lack of suitability for a particular purpose. A screwdriver is terrible for hammering in nails. That's not the screwdriver's fault.
Unfortunately, for my money, I think the only real way you can create an incentive structure which emphasizes stability and change is by offering some kind of form of insurance.
My father was an electrician who often complained about how he never got paid adequately for the stellar, stable work he did, and one day I asked him whether he ever thought of raising his rates but providing a kind of service guarantee, where if a problem occurred that could be traced back to his own work, he would step in and perform the additional work at a reduced fee. Naturally he laughed out loud, because that's not how business works.
Ownership of an already-mature product is sort of like providing an insurance policy by default, of course. And sticking with conventional designs can be a solid business strategy if you use their slow-changing nature to e.g. build the thing faster than you could otherwise. That's the strategy I'm using for my consulting: Stick with what we know best (Hugo+Bootstrap for a napkin sketch UI demo as fast as possible, then SQLite+Django+React to build out the main functionality ASAP too). Emphasize solving the _business_ problem over the shiny tech.
An ex-director of a French national security agency complained about exactly that during an interview, that you get more budget after a terrorist attack, or after you stop one that was well under way, but never if you avoided the condition to create a terrorist cell altogether, or nipped it in the bud.
The problem with "given more authority" I see is that management plucks these engineers out to make their day job basically "sit in meetings" if you're even slightly effective at simplifying life for everyone else.
Because that is the place of most leverage to place those people, but then those people are in a constant tug-of-war with the first group of "fresh ideas".
Eventually, the people who are in charge of the "prevention of bad architecture" become the bad guys because they (or me, I'm projecting) get jaded into just finding out what's wrong with something as fast as possible to be able to keep up with that workload.
You go from a creative role to a fundamentally sieve role with destructive tendencies, where you are filtering out the good from the bad as fast as possible, be.
First of all, not all new ideas are bad and "there's something bad about X" is not a "let's not do X".
Secondly, going from making things to shooting down things is intellectual suffering if you have a bit of empathy.
Some people on the "committee" with you don't have empathy & literally enjoy it - you're either trying to damage control on a case-by-case or building a "these assholes need to be fired" doc out of the meetings.
I realized what I would become if I conflated authority and respect ("respect my authoritah!").
Quitting was really the only way out of it. But it wasn't hard to explain to my spouse that i needed to leave for a job a level down and which paid half as much, because she could see me bringing my "why the hell do we have to do this" attitude home & to family decisions.
I hope that I live to see a time when software applies modern algorithms to classic designs and produce “hand tools” in software.
This. I recall the case of a couple of FANGs who on one hand expect their engineers to deliver simple, maintainable and robust systems to minimize operational costs, but on the other hand they demand engineers operate at the next level to be considered for a promotion, which means they are expected to design non-trivial systems which have a certain degree of complexity and require significant amounts of work to pull off. Therefore, as an unintended consequence, the pressure inexperienced engineers to push needlessly complex projects where they are required to design solutions well above their level of expertise, and put them in a position where their career is personally threatened if anything gets between them and their promotion-driven project.
All of what you said is true, but there are still people who think a minimalist, rugged and reliable solution is superiour. That maintainability is a value in itself (and thus, one should not choose the wildest, most experimental dependencies).
Until we figure out a nice metric for "removing complexity" and then rewarding for it, it's not likely to change, IMO.
I’ll say one thing though: all of those skills you mentioned as not being valued are extremely useful for indie dev/taking ownership. Shipping simple + correct code frequently is extremely possible with sufficient practice and discipline.
More to your point, this is why I switched toward being a research engineer. There is a higher barrier of entry, projects are quite technically challenging, and constraints often force thinking of a world of computing beyond the tiny sphere of the web browser.
It’s hard work, but I love it.
If this resonates, you are in the US, and looking for a change, drop me a note (see profile).
Not gonna convince anyone but hopefully someone reads this and starts thinking about such options. They are not as impossible as those in power would have us believe.
And also why the most frequent request from the users is: Please don't change anything.
The principal-agent problem looms large in software.
I think it is: "Please don't change anything I did not request"
(who does not hate updates that break your workflow?)
But they usually very much like changes, that makes life easier for them. Best way to find out, is to watch them using your tool and talk with them.
Please.
I blame Career-Driven Development for a lot of "shiny toy" (i.e. failed and complicated) projects.
Whether that's wrong is a deeper question - if it leads to better salary through job-hopping and promotions, despite a catalog of failures, is it actually the wrong approach from an individual engineer perspective?
I still say yes, FWIW; I enjoy seeing my projects succeed and thrive. But I know others may disagree.
From my view, that and pressure from the analyst racket are the main drivers behind feature bloat with self promotion a distant third.
everything about engineering group decisions are about creating a reason to use a newer framework in a way other people can vouch for.
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 and monetize the half-broken thing the team is working on now. Yet that's the only way out and the only way anyone gets to 1M users to begin with.
Not necessarily. It's just that most developers have never worked in a setting where they got to work on problems properly.
Solving real problems for real people is very addictive. There is a reason some people like working for startups. It's because you live very close to your users and when you make them happy you know.
The second interesting fact is that if you just plow ahead and solve many real problems fast you will eventually run into problems that are both real and interesting.
After having tried that there has been no going back for me. I am allergic to imaginary problems. It feels as pointless as watching people who are famous for being famous argue on TV.
I think we are all victims of our feedback loops. (University) Education sublely teaches us that the only important problems are those that are very difficult and preferably have never been solved before. Those same problems also make for better blogposts. In the real world the incentives are mostly opposite. Problems with no known solutions (or only really difficult solutions) are generally bad. They can be worth it, but you should stay away from them until you know that are worth it. Software engineers seem to almost pride themselves on not knowing what their users want.
It takes a while to scrub all that bad learning out and replace it with something better. Unfortunately some people are stuck.
This is a great insight. One can add value to other people's lives by applying known solutions in relatively novel contexts (e.g. building a CRUD form at XYZ employer), whereas it's very hard to add value to other people's lives by trying to develop entirely novel solutions (because the probability of success is so low). Most of our training however, focuses on the methodology used to develop these novel solutions, rather than on the application of the solutions themselves.
This was the feedback loop that worked best for me. imaginary problems and needless complexity go hand in hand, ruthless editing at the planning stage is necessary to combat it.
The endorphins from making someone's job less sucky are a way better high than solving some code puzzle.
There is no technical problem. The problem is nobody worked on actually marketing the product. Build it and nobody shows up is the norm.
I told them I'd buy another stick of RAM and scale vertically until I had more customers, and save money on staff in the meantime. The interviewer went cold, I didnt get the job.
Whenever someone asks me this question, I reply with a question "How many simultaneous users do you/we have today and what is our projection say for 12-18 months from now ?". If the answer is not clear, I tell them not to worry yet. If the answer is very clear but numbers are much smaller today (say 5-10), then I challenge them on where they think they/we could be in 12-18 months. A lot of times, it helps the other side see that they are mostly asking "How long is a piece of string".
We never saw anywhere near those numbers in production, but I don’t really blame them - it was a big company and you do what you can to get ahead. A lot of money was spent on infrastructure that wasn’t needed but nobody seemed to care.
I'd say they underestimate how long "just throwing money" (servers) at the problem can work.
If you earn decent money now, scaling number of app servers 10x times to serve 10x times the traffic will still earn decent money. Doesn't matter that "PHP is slow", deal with it when your infrastructure cost warrant hiring more/better developers to fix it.
Especially now. Pair of fat servers on some NVMes and 1TB of RAM gonna cost you less than few dev-months and that can serve plenty of users in most use cases even before any extra caching will be needed.
I think this started with the old Apache web server. When the www got started, that server did the job so everyone used it. The problem was it didn't scale, so all kinds of cool solutions (load balancers and such) were developed and everyone building something bigger than a personal blog used that stuff. For most the root problem was that Apache had terrible performance. Nginx has solved that now, and we also have faster hardware and networks, so anything less than HN can probably be hosted on an rpi on your home network. OK, I'm exaggerating, but only a little. Bottom line is that scaling is still treated like a big fundamental problem for everyone, but it doesn't need to be.
And overestimate how expensive it is to just add another server, or underestimate how expensive a rebuild is. But then, part of that is also that IT departments want the budget; if they don't spend their annual budgets on innovation, their budget gets cut.
Or in my neck of the woods, the EU subsidies will stop if they don't have anything they can file as "innovation".
At the beginning of a project, before I write a line of code, I try to: a) if it's user-facing software, get some UI designer input to shape functionality/interactions, not styling. To end users, the UI is the software, not just the shell, so mediocre UI = mediocre software. It can also illuminate needs you didn't consider that affect architecture, etc.; then b) block out the broad stroke architecture, usually on paper, c) intentionally choose languages/environments/tooling/etc rather than reflexively going with whatever we've been using recently, and d) spend some design time on a reasonably sane and extensible, but not overly detailed data model.
There's no perfect solution, but at least in my cases, it seems like a good middle ground.
The reality is that MVP should be missing most planned functionality and should really just be a few core features and functions that the rest of the application builds off of, the trunk of the dependency tree so to speak. That idea is, unfortunately lost on the majority of PM's, and ultimately it costs more time/money to get to a finished v1 because of it.
Unless you're working on something like the Linux kernel, that's an imaginary problem.
Those constants represent the markets supported by that app. By the time the app supports even a few dozen markets, every engineer involved will have exercised their stock options and left.
But their day job actually isn't writing code, it's solving a problem for an end-user; the programming language is just a tool.
Rethink your job from a coder to a problem solver and you should be able to get over the compulsion to overcomplicate things for your own gratification.
> Simplify the problem you've got or rather don't complexify it. I've done it myself, it's fun to do. You have a boring problem and hiding behind it is a much more interesting problem. So you code the more interesting problem and the one you've got is a subset of it and it falls out trivial. But of course you wrote ten times as much code as you needed to solve the problem that you actually had.
https://thehill.com/business/despite-widespread-protest-redd...
https://en.wikipedia.org/wiki/Reddit
https://backlinko.com/reddit-users
Equity is the entirely the answer for cutting through all the bullshit. At least in my head. I don't know how it plays in other people's minds but mine sounds like: "If we ship and go live, I get x% of all profit moving forward in my personal scrooge mcduck money bin". Pretty big carrot. It's kind of like time share in my own personal business, but I don't have much of the headache that goes along with running my own 100%.
This has some caveats, namely that equity in a 10k person org is often times not nearly as meaningful as equity in a 10 person org. Shipping your code 2 weeks early at Ford or Dell means what, exactly? If the code you are shipping is the business, then things are different. It also really helps if you care about the problem you are solving.
I'd say this - if the idea of direct equity/ownership doesn't get you excited about pushing simple & robust techniques, then you are completely in the wrong place. You should probably find a different problem space or industry to work in. Hollywood might be a better option if the notion of equity or straight ownership in the business still isn't enough to put your tech ego into a box.
I agree for small companies which are largely founder owned. I think outside of that, Equity doesnt do much because so much effort is put into obfuscating the value/share of the equity. If you cant see the cap table, and you cant see the preference overhang, the equity is as good as worth zero. There is no discernable value for a fraction with no denominator.
You see the most extreme versions of dangers of this in stories about governments and older companies having to pay insane salaries to bring FORTRAN or COBOL developers out of retirement to keep systems running. If you keep doing the simple solutions within the existing system, you risk creating a system so inbred that only the folks who built it can maintain it effectively.
For less extreme setups, it's still a balancing act to consider how much your unique and specific solution that is the simple option for you company starts closing you off of the larger hiring pools in more common technologies and patterns.
“I think we should use a Kubernetes cluster!”
“You’re joking, surely? This is a tiny web site with mostly static content!”
Next project:
“For this web app, I propose we use Kubernetes…”
I've often found myself now having issues even updating my resume, because what I did for the last year at work barely is explainable to other people on my team, let alone to someone in HR at another company. Or the more simple explanation is something that sounds like I'm doing work barely more complex than an intern could have done. Which often isn't wrong, but the intern wouldn't know which simple work to do.
My years of experience in the company's stack and org is valuable to the company, and nontransferable elsewhere.
On average, and depending on skill. Incentives are hugely important (probably the most important metric any manager could work on), but even they do not guarantee results. If you hire so many juniors that nobody is there to upskill them fast, you only get one lottery ticket per employee. Conversely, if you hire a bunch of geniuses and fail to give them incentives to work on realisable, useful problems together, you get two lottery tickets per employee at twice the price.
(This comment feels woefully incomplete. Does anyone know of good resources to learn more about incentive structures and how they relate to individual and company success? I feel like the problem is that incentive structures change massively when companies grow, so even for unicorns there's just a short sweet spot where we can actually learn how they are supposed to look.)
This mentality is often taken way too far. I had an old boss who wouldn’t allow me to write unit tests citing this thought process.
Even at places with decent engineering practices, I’ve seen so many examples of software where you’re limited to a one to many relationship for something that could and easily should have been implemented as many to many, rendering the product useless to many because a product person couldn’t stand to think a couple months ahead.
Some people seem to take this idea too far and basically assume that if a problem is interesting or takes away a tedious task, it must be overengineering, premature optimization, or an imaginary problem.
Perhaps a better way to phrase the issue would be “artificial constraints”, which would encompass the flip side too.
Every feature is done quick’n’dirty and eventually you have people whose full time job is to respond to customer complaints and fix data straight in the production database.
If it's something more fundamental like language choice or system architecture... Well fine YAGNI now but if you ever do need it you're screwed.
3 days later I deployed my “nice to have” fix and the performance issues disappeared.
I’ve also seen a company stall out scaling for years and lose multiple million-dollar customers despite having a novel in-demand, market leading product because they refused to do anything to clean up their infrastructure.
I was creating a very important demo once, features i had said were important were classified as YAGNI. Leadership eventually saw that we couldn’t deliver without said features. YAGNI bit those teams in the butt.
these things happen all the time internally to companies but get ironed out internally as well.
But tautologically you can't take YAGNI too far, if the "YAGN" part is actually true :-). But that is always under debate.
“You’ve just wasted $15,000 on two months work with a team of contractors”
The project may also have been doomed because $15k is not very much for something like they described.
But again, fully aware that they probably picked a random number. I’d have just added another zero to make it more realistic.
Either you have the bootstrap founders that will trawl through fiverr to find the cheapest labor (the same types that will scoff and get insulted at anything over $10k), or you have the well-funded founders that will pay whatever it takes.
From experience: Cheapskates and low-ballers will never be happy. They always want something free, more haggle room, more discounts, and always have high demands and expectations. The best thing one can do is to price yourself away from them.
all the author needs is a wordpress site with a couple plugins and a few weeks of back and forth on the design work. if you can't make a good profit on that with a $15k invoice, you're doing something very wrong.
That sounds really high to me. I personally found 15k way too high already; guess it depends on the details/market/circumstances
I find the rest of the article to be bizarre. The discussion around retail banking software seems unacceptably incurious and a very likely incorrect diagnosis of the cause of the problems (it basically stoops to an ‘I could do that in a weekend’ level of criticism[1]). It then transitions to a screed about Goldman Sachs which is, as far as I can tell irrelevant (Goldman do very little retail banking; their software development will be quite different to that done for retail banking), and then some description of how the author thinks (all?) large companies are (mis)run. I don’t know if Goldman was meant to be a prototype for this model of company management but it seems like a particularly strange example (in particular, they still will have some remnants from the culture of being a partnership, so they’ll be run somewhat differently from other big investment banks).
I found the second half did not ring true. I’m sure software projects fail at big companies (including retail banks, Goldman Sachs, other investment banks, tech companies, and so on) but I don’t find the reasons given in the article convincing to the extent that I think that section could have been written by someone who had only ever worked at very small companies. But maybe it’s just me and most companies are so obviously terribly wrong in these ways that no one even bothers to write about them and so I only see subtle ways they go wrong like projects dying off due to management acting in bad-faith ways or rewarding people for things that aren’t actually so good for the company or whatever.
If you’re interested in better discourse around certain kinds of bureaucracy, look into moral mazes.
[1] generally ‘I could do that in a weekend’ is code for ‘I could do some minimum thing that doesn’t actually solve whatever the important problems are in a weekend’
> Have you ever heard about those three web engineers who figured out that secure online banking is actually quite an easy problem to solve?
> The storage and transfer of numbers is not a particularly hard problem.
These quotes are so incredibly disingenuous that make me question any advice OP has to offer.
First, banking is quite a complex domain, and it's complexity increases exponentially with the kind of services that you offer.
Second, banking is a highly regulated industry, which makes everything why harder than "it should". In fact many "neobanks" have appeared in the last decade, and this is usually their biggest hurdle.
Third, online banking needs to deal with quite a few hard technical challenges. That's why the likes of Monzo, Starling or Revolut often given tech talks.
So no, imaginary requirements weren't the root cause of bad software when I worked in banking. A 20+ years old big ball of mud, inability to pay off any tech debt (unless you wanted to get literally yelled at in front of the entire team), flaky and severely insufficient tests, and a very toxic working environment were all causes of bad software.
I'm sure Google as an org has accrued plenty of staff that are working on mild to non important tasks over the years, and I get where he's coming from, but reality is far more nuanced.
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 organization, both directly and indirectly.
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".
They are acting rationally within their belief system of making money.
Enterprise software is exactly that, software used by enterprise -- it doesn't signify any good qualities (far from it) only that it provides a cost-effective software solution to a defined business need.
The issue is when corps get bailed out, overfunded, or have revenue mostly outside of software (e.g. gov't contracts) as it eliminates cost-effective from the equation... so you just end up with buggy messes (code as a cost center).
You'd have to work in the tiny niches where tech is the true product to find good development ...and even then...
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 of experience from their workers. I'd love to write C89 in the dark corner for the rest of my days for reasonable compensation, but I don't see those jobs, what I see is billion keywords k8s spring boot react query metrics jaeger aws yada-yada.
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)
"If I get 5-10 of these done today, I'll reward myself with..."
Or use your imagination in someway like kids do with action figures. It can seem strange but there's ways it less mundane indirectly.
Simple > Complex.
It's amazing how many otherwise brilliant people dive headlong into project without considering these basic principals or even intentionally brush them aside.
"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%."
Maybe optimal performance is a feature? Feature worth working on from start?
Reader, we had 25 devices.
I remember working at one place where somebody built a new framework to solve a common problem we all had. He pitched it to all the other devs in a meeting and I remember being confused about it because there was a standard framework that solved the problem already and did it in much simpler and more elegant way. (To be fair to him, this standard functionality was only recently introduced.)
During his presentation, I asked why the standard solution wouldn't work for him. It turns out he wasn't familiar with it. Fair enough, so later I messaged him and showed him the standard way to do it and how much simpler it was. He couldn't be swayed.
He just couldn't accept that his complicated solution wasn't necessary. He constructed scenarios where his idea was needed, even though I saw solutions to those scenarios using the standard framework.
Interestingly enough, one of the scenarios where his custom thing was needed was in some tests he had written where he did some complicated things to set things up. I looked at the tests and even there saw those complicated things weren't necessary! There were ways to simplify what he was doing so that the tests were better written and didn't need his custom tool.
Anyway, he wouldn't be convinced. And because he couldn't be convinced, we got stuck with his solution and saw people continue to work on it, add more functionality to it, fix bugs, etc. All of that work was just a waste of time when we could've relied on a standard solution, which was way more mature and way simpler.
All of this drove me crazy, but I realized that sometimes people are just unable to see simple solutions to problems. Worse, having one complex solution begets more complex solutions elsewhere.
This person might just have been terrified of admitting that all the (very tangible) time they spent on payroll building this thing was for naught. It’s unclear how their manager might have responded to that. And they wouldn’t have been able to put „built system doing X used by Y developers and deployed to Z customers“ in their resume.
The reasonable choice often doesn’t have much skin in the game.
It's hard to admit that your baby is ugly.
A restauranteur wouldn't develop a menu without input from a chef or prior experience as one. A layperson wouldn't design a real building without input from an architect or engineer.
Yet for some reason a myriad of non-technical people (read: laypeople) feel empowered to design, spec, and strategize about software. It still boggles my mind that "product management" is a real profession.
They shouldn’t be checking in after two months. They should have regular check ins.
They shouldn’t have had such a vague brief.
They should have discussed a wide range of off the shelf options from the get go to see if they needed something bespoke or not.
Replace those devs with ones who are focused on the right things? Great, but you still have the other problems to deal with (scope creep, uninformed clients), not to mention a host of other things that can derail a project, such as poor communication.
tl;dr Most projects are poorly managed. Poorly managed projects tend to fail.
Further, project managers tend to focus on delivering the product stakeholders have asked for on time and on budget.
Product managers however I find are frequently searching for a new expanded scope of stakeholders to brag they're solutioneering to. I find them more often in the "solutions looking for problems" business than I find developers, or at least developers are only doing it on a micro-scale, while product managers will take an entire team/org on 6 month fruitless missions to build software destined for the dustbin.
I don't know anything about banking software, but I have a hunch the author underestimates the complexity (as is typical for HN). The Efficient Markets Hypothesis would suggest that if it were so simple to make banking software, then someone would do it.
From October 2022 to now the shareprice tripled, adding half a trillion dollars to its market cap.
Explain that in terms of the Efficent Markets Hypothesis? "share prices reflect all information" - what half trillion worth of information change came out in 2022? and what in 2023?
What about insider trading laws? How can we say "share prices reflect all information" when we know there are people who have more information which would give them an unfair advantage, which means the current shareprice cannot be reflecting the information they have?
i now take great pride when my code looks boringly obvious.
And the gap is widening...
Need a bog standard app to stream audio files? Give it to the person you hired right out of college, or maybe even the summer intern. She's never built something like this before, so to her it will be a challenging novel problem. A (somewhat) more experienced developer may need to provide initial guidance and review code, but that's a comparatively minor time investment, and besides, the act of mentoring someone else should keep it interesting.
this runs into another common mistake businesses make: putting people onto a task because they're available, not because they're suited to it (in any sense).
the junior person (+ a little mentorship) would be great for the job, but they're mired in some big project. but hey, you've got this super senior fellow sitting around waiting for work, and we can bill the customer more for them, anyways.
I do think that “imaginary problem” is the answer most of the time though. Most things that look like unnecessary complexity or hobby horses really are.
Sometimes boring is just pure torture.
Then we ended up deciding not to make money out of it that way. So we burned enormous effort and created a horrible design for no reason.
So IMO the problem is usually with the way requirements are not usually well understood even by the people asking for them. Later on it becomes clearer what is needed but you're stuck with false assumptions baked into your design in a way that you never have bandwidth to remove because you need so much bandwidth just to do normal work....because of those assumptions.
YNGNA is generally true, but Product's should have a very clear vision of what kinds of entities the system is going to handle over then next 36 months before they start asking for specific functionality. I've seen extra shit get built, but I've also seen e.g. a travel booking system that was built without a "flight" being a first class entity. Flights were deduced on the front end from attributes attached to seats... which worked well until a PM asked for the UI to show fully-booked flights, which HAVE no available seats that make it to the front end. Same product couldn't handle the booker and traveler being different people, when they knew from day 1 that it would be a necessary feature. It would have been little extra work to incorporate into the data model from the beginning, even if the two values were always the same for a while.
I think the majority of the technical debt I've seen that isn't ci/cd related is disconnect between the domain model the product team is working in and the data model the engineering team is working with. Formalizing that domain model is now one of the first things I do when joining a team, so everyone agrees on precisely what the major nouns and verbs are and how they interact. Not just for the current system, for where we think we will be in 2-3 years. With everyone doing agile, it's amazing how many incompatible, un-written assumptions you discover that hadn't been ironed out.
Implementing something else “because if they implemented the real spec they would get bored” is too much psychology.
For the most part, the software I see works well for what it does, and either has far too few features, or else all the extra stuff they added is stuff that people actually use.
On social media things are different, that's been bad and unsalvageable from the moment endless scrolling made it into something people spend significant time on.
1) it's debuggable 2) it's fixable 3) it does exactly what you need to do how you want to do it without any extra cruft and nonsense.
Libraries or game engines are too generic to be fast and easy to use because they need to solve for every possible use case. And even then, there are still edge cases where what you want to do cannot be done because of the architecture of the thing and so you're stuck with a slow weird ducktape solution to get around the 3rd party code's limitations.
I want to get paid to solve real fucking problems which has a factual validated need from real people.
Most people are terrible professionals. Writes code to have fun and expects to be paid too. And even blogs about it too.
I want to be in the trenches. Hard work. Real work. Not some glamorous bullshit that lasts nowhere. Quality long lived treasure is what I strive for.
And I dont want to progress by applying popculture technologies because some punks subjective opinion wants to have fun. One has to be a prick and tell these people off because they shovel shit and pad their own backs when the re-shovels it with a new fad.
I want to progress by making slow surgery like precision work. I want to make sure that what I do sticks and is sound quality, no code is written for fun. Code is a fucking liability.
Between the scams and the hustle, the number runners and the pick pockets, real people with real quality minds do real good work. Those are the only programmers worth being around and hire. Everything else is just a waste of time and mental capacity.
So many morons in this business. It's really too much.
In my code I tend to leave negative space. A spot where a feature could logically fit, without having to really design that feature before we need it. And as my comfort with compound refactoring has improved, some code smells have fallen off of my veto list. If we need to do X then this solution will stand in our way, but we can alter it here and here if that becomes a problem. It works well for a team of one, but it can be difficult to express in a code review, when someone is adding the fourth bad thing to the same block of code and now I’m pushing back for odd sounding reasons because my spidey sense is tingling about bridges too far.
But the main argument is off - What some classify as imaginary problems is actually building in the wrong types of affordances. The only way to know the difference is by knowing your tools and the problem domain.
The root of bad software is leaders lacking practiced learning.
They’ve put their heart and soul into creating this app, and it has some amazing features:
A state of the art recommendation system
An algorithm generating the transcript of all your streams, in real time
Your front page loads in sub 200ms times all over the world
A streaming protocol and client build almost from scratch, in case you don’t want to rely on Facebook live
A service that allows you to easily integrate over 20 ad exchanges
What a dumb article.
This is just made up. If you hired consultants and they pulled this lawyers would be involved.
I stopped reading here. Why continue reading something based on a fake premise.
Ouch. The tone of the article is a little harsh, and I’m not sure if snippets like the above are intentionally hyperbolic, but there is a fair amount of truth in it.
Most of my career has involved convincing peers to do less, and solve simpler problems with simpler solutions.
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.
It’s not impossible that some of the problems I see others manufacture have a genesis in past traumas they are trying to avoid (some coping mechanisms are healthier than others).
Yes, they should have planned to be able to roll back, but it wouldn't have been simple. It would have been very difficult, and if they were fastidious enough to plan for a rollback they presumably would have done the development and migration in stages and performed parallel testing on the old and new systems, which would have removed the need for the rollback in the first place.
This meant I needed to deal with more JavaScript than I originally intended with my career, and eyerolls from backend architect types, but projects go much smoother than in my past, that's for sure.
I run into this more often than problems I imagine. A whole series of what ifs and folks imagining things. The worst part is the fixes to their imaginary problem are usually not well thought out and drive things towards worse choices.
I’m a big believer in getting version 1 out the door as problems people imagine often… are never relayed by the actual customer.
I often work with some routing software (let’s say routing packages). There is a simple mode that works great. Anyone can use it.
The issue is people want to establish say 20 rules about how / when / what is routed. Business folks insist that it be “easy” for “anyone to use” just like the existing easy mode.
This is doomed from the start. We can make it easier for sure, but if you have 20 rules with different weighted priorities:
1. It is complex for most people to think of. It will look complex because it is complex.
2. That’s ok because the guy with 20 rules probably has thought about them and understand they have 20 rules.
Then we give them UI to visualize it all and customer is happy.
But the business folks are upset because the visualization is complex… and there we are again.
For the record I usually get through this slog and everyone is happy in the end, but it is a slog due to imaginary problems.
It's the same as the phrase "(premature) optimization is the root of all evil". Does it mean you should never optimize? No. Does it mean you should always optimize as a last step? Also no.
Here's the full quote: "Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%."
It's way more nuanced and basically says: "Stop wasting time on optimizations with little gain, but still do them where they are useful/necessary."
Right now I'm working on an embedded device running a small Linux. Our resource usage is well within the bounds, so thinking about better architectures or optimizations is an imaginary problem. Right? No. Not at all. Making our software smaller and/or faster doesn't only mean we can put on more software, it also means we could produce cheaper because we need less resources.
Thinking about and experimenting with different architectures or newer technologies also seems like imaginary problem solving at first, but there is a good possibility that you improve your system as well. A better architecture could make your software more maintainable or give you the flexibility to implement new features in a way, that was really cumbersome with the old code.
So while I agree with the sentiment that you should not implement things you don't need, I also think that there should be room for people to experiment and try out different things. Because sometimes, the people working with the code the longest are blind to it's many shortcomings. Because it's normal for them to just work around them. But getting rid of those shortcomings can save you hundreds of man hours of work in the long run.
To cut a long story short: Do experiment. Do think about problems you might have in the future. Do the mental exercise and think about how to improve your current code and architecture. But don't blindly implement it
Always evaluate what your trying to do. Check if it improves the things it's supposed to improve and also check if it doesn't make matters worse elsewhere. Get to know the tradeoffs and make informed decisions if changing something that works to something that's better is worth it to you.
In other words, when you have a hammer, everything looks like a nail.
This article, its art and its font choice, shall be preserved forever in the archive of Historical Documents.
Our eternal response to unnecessary complexity? "Never give up! Never surrender!"
--
ADDENDUM:
The article makes a good case for formally adding "manufactured complexity" and "miscommunication complexity" to "accidental complexity" and "necessary complexity".
They are quite common distinct causes.
Been through that at several companies now.
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.
Crucial to fight against this kind of stuff.
These aren't imaginary problems but interesting solutions. I'd bet that card punching programmers working on the first computers were the first to build interesting solutions along with addressing requirements. Look at how far managers have evolved since then.
I beg to differ. This might have once been true, but no longer. Now developers demand a massive arsenal of dependencies before they are even willing to start on any project.
You say you need a web page and a few events? No problem. I will just sprinkle in some React, Redux, Grunt, GraphQL, PM2, and a plethora of plugins for each with a cascading list of dependencies for all those plugins. We absolutely cannot do less, because the risk of writing original code is too costly and we value retaining employment (blaming someone nameless outside the company).
> Much like victims of childhood hardship or abuse can find escape in fantasy books, victims of enterprise programming or freelance web development can find their escape in solving imaginary problems.
* Communicate effectively - avoid middle layers
* avoid over imagination / premature optimization
* Incentivise for organisational efficiency
While it’s possible to prioritize problems that don’t affect most people (squeaky wheels) it’s a hell of a lot more effective than most of the methods I know to have a very low barrier to contacting you for users, and fixing the things that come up.
We should focus on the problems of "now". The future will catch up.
— Today You Need a Rule Book, 1973.
Maybe a Buddhist could say
bad software = -1 problems
Bad languages and tooling is the root of bad software.
