But the market doesn’t care.ĭisk usage isn’t on the list either, though occasionally it appears in small, low-contrast print below a “Download” button. We can invest time to test, refactor, and improve, but it’s entirely possible no one will notice. And since there’s no comprehensive way to measure defects in software (surely if we knew about them, we would have already fixed them?) it’s not a feature that can be compared between products. The Agile age has taught them that bugs will inevitably exist and you’ll fix them on an ongoing basis. There’s no way to express reliability in a way customers will both believe and care about. “90% unit test coverage and a full suite of integration tests?” Nobody knows what that means and if you explained it to them, they’d be bored. How exactly would you say that? “Bug-free?” There’s no way to ensure that, let alone prove it in a product demo. You may notice reliability isn’t on the list at all. The pressure is always on us to build features, features, features. And god forbid any red-blooded board of directors would allow the company to take a six-month detour from its product roadmap to work on technical debt. If you poll your existing customers about what you should work on next, they’re going to ask for features, not speed-unless the software is so slow it borders on unusable. If you spend your time optimizing a core process while your competitor develops a new type of report, you’ll lose eight of your next ten sales over it. We can all agree that speed affects a user’s entire experience of an app. The software may in fact be very slow, taking several seconds to respond to a button click, without making the “instant updates” claim a lie. They can all be proven in a one-hour product demo. These are falsifiable statements either the software does these things or it does not. Fine-grained access and security controls.Weekly and monthly reporting at multiple levels.Integrates with Delivery Pro, Supply Chain Plus, and Super Point-of-Sale systems.Tracks inventory across multiple warehouses.Its marketing materials will consist of several high-res stock photos, a bold color palette, and statements like the following: Take an inventory management app as an example. To businesspeople and customers, software is a list of features. However, it’s not the way software is packaged, marketed, or sold. Software is envisioned by engineers as networks of interacting components, inputs, and outputs. Speed is a feature, reliability is nothing So instead of relying on the myth of laziness to explain slow and buggy software, we should be asking “what widespread forces and incentives are creating an environment where it’s hard for software engineers to do their best work?” But I strongly believe it’s the natural human state to work hard and make excellent things, and we only fail to do so when something repeatedly stops us. Prokopov’s answer is “software engineers aren’t taking pride in their work.” There’s some truth to that. We could find new ways to compress assets. We could write tiny, purpose-built libraries. We could make them faster, probably by orders of magnitude. At the very least, there are optimization opportunities in almost any modern app. And exponentially larger without a corresponding increase in value. Most developers know better than to say things like “it’s a smartphone OS, how hard can it be?” or “my spreadsheet app in the 90s was 10 kilobytes, how come Factorio is a full gigabyte?” If you weren’t there when it was built, you can’t reliably estimate all the hard knocks and complexity that went into it.īut that doesn’t mean there’s no room for objective criticism. The aforementioned posts on this subject come across as about 80% fair and reasonable criticism, 20% out-of-touch grumbling. DOOM, which came out in 1996, can run on a pregnancy test and a hundred other unexpected devices meanwhile, chat apps in 2022 use half a gigabyte of RAM (or more) while running in the background and sometimes lock up completely, even on high-end hardware. Among people who write about software development, there’s a growing consensus that our apps are getting larger, slower, and more broken, in an age when hardware should enable us to write apps that are faster, smaller, and more robust than ever. It called to mind Maciej Cegłowski’s post “ The Website Obesity Crisis” and several others in the same vein. I recently stumbled upon “ Software disenchantment,” a post by Nikita Prokopov.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |