Pushing out something completely broken that doesn't do what it's supposed to is definitely not going to work (duh!). Pushing out an app that solves the problem of managing shopping lists that has a bug where it doesn't work given a particular set of circumstances will still lead to many people using it if the users don't have any alternatives and it's better than using a piece of paper.
Software quality is important to companies because it means that they can spend more time building features instead of fighting fires, and because low quality represents a threat that a competitor could launch a better, less buggy app. Users mostly don't care so long as the app works well enough to do what they need it to do (but they're not dumb, they'll still pick the least buggy option if there are alternatives..).
A high level of quality in software is not important unless you're entering an already well-served market. I wish it was.
When software is designed to focus on extracting maximum investment per person, and focus on whaling vs scaling, then you get loot boxes. Suddenly overall software quality matters a whole lot to the user base.
There's so much trash everywhere that is earning millions (book reading apps, silly chart-db software, proprietary SQL databases etc.).
I was quite shocked by the levels of disfunctionality in the software engineering sections of the company I worked at yet still, the company has huge success. We basically got requests from the product team to make something work in a day or two and even though it was completely horrible code that absolutely paralyzes us at some moment in the future, the company still reigns.
This is a great phrase that I'll have to remember. Pretty much all enterprise sales is "whaling".
My assumption is also that enterprise software contains _more_ bugs than consumer software.
Solving the right problem the wrong way is more important than solving the wrong problem the right way.
As an engineer, that has been one of the most important lessons for me in my career so far.
And I don't intend my loot box reference to be taken too seriously. The gaming industry isn't any better. As an obvious example, Cyberpunk 2077 was delivered as a hot mess only to meet overhyped timelines.
But look at games like Apex Legends, Fortnite, etc. They work very diligently to ensure the core gameplay is solid so streamers will provide eyeballs, driving lootbox sales. Whales provide the biggest investments there, with some individuals spending thousands of dollars for cosmetic lootboxes in what would otherwise be a free game.
Then look at games like Quake Champions which should've been successful in the same way, and completely failed because they didn't focus on making the core game tech (net code specifically) rock solid before attempting to monetize. They immediately lost the pro crowd and failed to convert the people playing Quake Live (or even the die hard Q3A players).
Enterprise software often doesn't spend enough time improving core process loops, or worse, provides too many core loops making the experience disjointed and unproductive.
And don't get me started on security/privacy issues.
I've been saying that for a long time, but I don't see as a problem in itself, but as a fact of life.
The problem comes because people get the wrong impression that "state of the art" is always a compliment and terrible usability is best of possible worlds.
I'm reminded of this every time I try to teach my mother anything about Android or Windows. Or even when I must deal myself with a new app with its quirky "state of the art" GUI.
I’d say better way to say the same thing would be ”Unless you are building something truly innovative and unique that people must use anyway no matter how bad the experience is, software quality matters.”
But also, solving it the wrong way may create an opportunity to do better.
The cultures that tend to ship buggy software also tend to be the sort of cultures where the quality doesn't improve in response to a competitor however. But so far almost every software business has ultimately failed so being on top for a decade because you shipped some of the solution earlier works better. Customers are more than happy to buy exceptionally buggy software and games.
I wouldn't go that far. All the cases you cite are of products that definitely classify as substantially better than what they replaced.
Before Gmail took over the market from Hotmail there had been several other companies that failed due to only being slightly better.
Yes you can beat the "first mover", but doing so is hard and requires an almost revolutionizing better product.
For example most ecom apps/sites are surely ”unique” based on how you described it, but customers have nearly unlimited options/alternatives these days.
Even then, it's not what's important. The core important thing in the product is that it does a job the customer needs done. If you write a program that provides complete feature parity with the incumbent with better engineering principles, you're going to lose because the engineering principles aren't the job the customer needs done.
Where it will make the difference is that your company will be able to respond to changing requirements better than the incumbent.
So solid software engineering is never the product for the customer. It might be the product for the company, depending if the company actually needs the improved developer efficiency and happiness it provides.
Another. Industries that are oriented towards tradeshow or holiday launches. It ain't like they're going to move NAB or Christmas just for you. Inevitable feature pruning occurs.
Having said that, I wonder how many of the great fortunes have been built on horrid, half-finished websites and associated software that were all about being first out of the gate and heavy marketing.
An interesting subcase is software that is difficult or impossible to update vs. immovable deadlines. I guess in a world that consists entirely of one silly internet surveillance marketing company after another is doesn't really matter much anymore.
The idea is that it does what it says on the tin, without fanfare, robustly, usably, accessibly, localizably, and dependably; providing a user experience that gets out of the way of the user, in a manner that does not surprise the user (even "good" surprises can be an issue. Boring software can be just what the doctor ordered).
In my book, that's the definition of "quality."
I'm working on an application that has been over a year in the making. Its functionality is something that I could have popped out in a month, but making sure of the Quality of the app has necessitated that I spend a great deal more time, "polishing the fenders."
If this were a commercial app (it isn't), then it would have been unbearably expensive for a startup.
I tend to write test harnesses in a day or two, that have similar levels of functionality to this application.
High Quality is significantly more expensive than even "decent, but lesser" quality.
Sure, but before that they generally make a lot more money than the second and third mover. When all is said and done, Atari and Yahoo did much better than Colecovision and Lycos.
The risk with being the first mover is that, having easily seen off competition from the second and third mover, you become complacent and stop moving.
I consider everything I do, "engineering." Been doing that, all my adult life.
Feel free to look at the stuff I do (I link to it in my HN profile). The app I'm working on isn't there (yet), but a number of its components are. It's still "under wraps."
I read a book, where one of the characters is a smith. It has this exchange, between him, and another character:
"Always do the very best job you can," he said on another occasion as he put a last few finishing touches with a file on the metal parts of a wagon tongue he was repairing.
"But that piece goes underneath," Garion said. "No one will ever see it."
"But I know it's there," Durnik said, still smoothing the metal. "If it isn't done as well as I can do it, I'll be ashamed every time I see this wagon go by -and I'll see the wagon every day.”I witness on a daily basis PRs that have no body getting merged with absolutely zero comments and a blanket approval as long as it passes our (broken) CI pipeline. I witness obvious poor quality in the code, but engineers want to seem like they are working and will just blanket approve PRs, while i'm in the middle of writing up my code review denying the PR.
If you are a developer on a team and want your codebase to be high quality, you end up no longer writing the code and instead spend all of your time gatekeeping via code reviews. This leads to burn out.
The obvious answer, is to hire experienced, skilled, capable engineers, and instill in them, the same reverence for Quality that you have.
Like I said, Quality is expensive. Very few companies like to pay the premium.
So I would say engineer is a poor term, but also the only one we've got for now.
This is true and, once you get over the myopic code focus that most of us shared in university, incredibly self-evident. "Users prefer to use the thing that solves their problem better than not using the thing." I mean... yes?
The real takeaway is that "software quality" means something very different to users than it does to developers. Developers want efficient, ergonomic libraries, aesthetically pleasing logical structures, and elegant software designs. That's what we call "quality". Users just want their damn problem solved, and if they can GET software like that which solves that problem, then you bet they'll buy it, but if they can't then anything which actually solves their problem is far better than doing it by hand.
This was the first big lesson I learned out of uni and it's stuck with me ever since. If you're interested in making commercial software, you're not there to solve the problems YOU think are important, you're there to solve the problems YOUR CUSTOMERS think are important.
What happens if you release it and it turns out that nobody likes it? I'd have preferred to spend a month releasing a lower-quality app, and then spent 11 months improving it (while people use it and I learn more about what they want) rather than take a year releasing a high-quality app nobody wants to use.
This assumes you aren't just building it for fun, though, in which case building it is the point, and you don't even need to release it afterwards.
But I also follow a development methodology that I call "paving the bare spots."[0] It adjusts the design, as the project progresses. Not for the faint of heart. It means that I may toss out a month's work, because it does not fit the user experience (which is under constant revision). We have also made a couple of major pivots, during the project, to fit new realities.
I have probably tossed out three months' worth of work, as the project has progressed. Happy to do so. The best code, is the code I don't write.
The nice thing is, is that the product is constantly at "ship" Quality. Makes demos, user testing, and begging for money, easier.
[0] https://littlegreenviper.com/miscellany/the-road-most-travel...
Windows and Android keep reinventing the same wheel even though (especially Windows) is basically still in "Windows 95" mode - getting fancy with a phone ui is just trash.
- [Probably erroneously] ascribed to Aristotle
But naysayers will say we are "bikeshedding."
Meh. Whatevs. I do things the way I do.
In the elder days of Art,
Builders wrought with greatest care
Each minute and unseen part;
For the Gods see everywhere.
I’m not sure to which extent I agree with this piece’s medieval outlook of seeking and expecting perfection in the past, not in the future, but it doesn’t detract from the quality of this piece of writing. (Same for Tolkien, for example.) (And the poem actually talks about improving on the past, not venerating it; citing this part in isolation is a bit misleading.) (Now that I’m comparing these two quotes, the difference between “because the gods will see” and “because you’ll know it’s there” is... probably not worth overanalyzing, but at the same time intensely amusing.)
So it is not exactly like you've said:
> You can't design it first and then go and build it.
You can design, but you cannot build.
A process of building by a design can be paralleled with deploying software -- suddenly there is a hairy real world, not all the hair was considered at the design phase, and either we hack around existing software (i.e. design plans), or call a programmer to redesign.
Large software project, whether you're a developer of one or a team (and probably more commonly occurs in a team since it's large) will have warts. It's harder to manage complexity as the projects size increases since it accumulates and it accumulates fast.
In other words: users do care. They just don't have a choice.
That's not the same than users "not minding" bad software.
You can't design it in full in one go, but you can design it and then incrementally update said design. Sadly many (companies) do not. But you can define the problem(s), the scope, the scale, and then design a solution appropriately to meet those needs (for a defined period of time). That's what distinguishes software engineering from hacking. They both have their place. Many companies claim to do the former but are mostly doing the latter. Software is still early in its life and as various kinds of system designs stabilize, so will the formalizations around what it means to be a software developer. Reading a book like Designing Data Intensive Application's you can't help but see those formalized topics budding.
It's not exactly a "one-man show," but I'm the chief architect, and the only one developing one of the three servers the app uses (I was also the original architect for another server, that is now being run by a different open-source team), I am also the only one developing the native iOS application. I may be writing some adjunct apps, once the main one has been released (like Watch, Mac and TV apps).
But we're a team. It's a 501(c)(3), with a mission to Serve a specific demographic. We have the advantage of being intimately familiar with the demographic. So far, we haven't had to shell out much. If they decide to write an Android version, then it may take some extra dosh. The good news is, the app is in "constant ship" state, so asking for funding is fairly straightforward. We just need to loop the person into the TestFlight group, and Bjørn Stronginthearm is your uncle.
Despite that, hotmail still exists.
While first mover doesn't guarantee success, it's certainly an illusion.
Early on I swapped from yahoo mail to gmail to hotmail because gmails spam filtering wasn’t good enough. Among my fiends Gmail really won on UI not space.
Somewhat weird mindset. It is natural that when a new market gap is discovered, the first iteration of products are crappy and do the job just barely. Applies to software, cell phones, forestry machines, water toilets. Having a mindset where everything should be perfect from the start will get you nowhere.
When I do stuff for myself I apply the same principles I apply at work. It's insane how easy it is to change stuff later on. Didn't think about this use case before but now you do? Because I have properly maintainable code that is readable its very easy to change and changes are only needed in one place instead of all over the place. Knowledge of the right thing is kept in the right place instead of implicit knowledge all over the code etc.
It also helps to have 'one team be responsible for each service' instead of 'everyone can work on everything'. It's insane how fast you can move if you know the code well and it's maintainable.
I also pretty much never get questions about the code that I pass on to others.
I write about my process here: https://littlegreenviper.com/miscellany/leaving-a-legacy/
(Long screed. Few read it).
This is ZERO snark, but I'm genuinely curious for lots of examples. I ask because I'm confronted with this problem ALL THE TIME working at startups that obsessively focus on visual elements that won't move the needle, versus being obsessive about solving pain better than others.
I need to start building a list that I can just pull out at a moments notice.
Would love to hear more!
As a designer I’m a bit embarrassed by the trend to describe ourselves as product designers. To me a product designer makes chairs and coffee tables.
Apple also displays extremely high quality code, in the areas that are exposed to the public.
I have not seen too much Adobe code, but I’m told you can eat off the Photoshop codebase.
For myself, I need to keep my scope fairly humble, but I get great joy from it.
It sounds like a gratifying environment. Good show!
The only reason you can design a bridge beforehand is because (millions?) bridges have been built before so you can apply the lessons learned. Even if your bridge is "unusual", it will still be similar enough to older bridges so you don't have to invent the vast majority from scratch.
Other kinds of engineering don't have the luxory of leaning on the prior experience so much, simply because there is less of it. SpaceX's reusable rocket could not have been be fully designed before built, simply because nobody built a reusable rocket before. But it could be done through iteration, which is just another name for experimentation.
Software tends to be less like bridges and more like rockets... all of which falls within the spectrum of "engineering".