Ask HN: How to Create “Boring” Software?
9 comments
Check for the error returns on everything. Spend time in a profiler, and optimize only the parts that matter. (boring code tends to run on limited systems so optimization is important!)
Trying to handle every error can also be a distraction though. I would suggest to only try to display errors that are likely to occur. It’s okay for a few unlikely errors to be not surfaced other than with a cryptic “there was an error.” This can shorten development time by a lot depending on your architecture.
No, boring software checks for all errors. It might only log the unlikely ones, but it has a log for them all so that if any happen that shouldn't we can figure out why.
1. Pick vetted and proven technologies to build with.
2. Principle of least astonishment
3. Use colloquialisms in your code. Every pattern should be easy to find (or close to) examples of elsewhere.
4. Use a linter/typechecker if not automatically provided.
2. Principle of least astonishment
3. Use colloquialisms in your code. Every pattern should be easy to find (or close to) examples of elsewhere.
4. Use a linter/typechecker if not automatically provided.
> durable products
An example emerges in the discussion within a parallel thread, https://news.ycombinator.com/item?id=28574624 , about extending the syscalls in Linux kernel. Unfortunately, some interpreted in the past "unallocated" with "available", so now syscall numbers in some customizations of the kernel vs the official one have conflicting uses.
An example emerges in the discussion within a parallel thread, https://news.ycombinator.com/item?id=28574624 , about extending the syscalls in Linux kernel. Unfortunately, some interpreted in the past "unallocated" with "available", so now syscall numbers in some customizations of the kernel vs the official one have conflicting uses.
adding to mdp2021's interpretation:
> Boring here seems to mean "reliable and easily understandable"
Another way to think about this is to consider the context that the software is used in, from the perspectives of users, operators, managers. Users want the software to be reliable, support their current browser, help them do the task at hand, and not corrupt their messages / lose their rent payment / leak their credit card numbers. Operators want to get a good night's sleep without getting paged because the site has fallen over again, and when things go wrong, want to be able to draw on an existing body of technical knowledge (documentation, bug reports, known workarounds) from the community about the known failure modes and shortcomings of the technologies that are being used. Managers want it to be relatively easy and cheap to hire new people to maintain the software when the original designers and developers of the system quit for better jobs / retire / are promoted away, want the system to be relatively cheap to operate, and want the system to be relatively flexible and modifiable so it can be bent to accommodate new requirements.
> My peers are building projects with short lifespans to get into the industry, which works to get a job, but feels like starting a bad habit.
Your peers are pragmatic. When I interview people for software engineering roles, I am mainly looking for problem solving skills, some fluency with basic data structures, ability to translate idea for a solution into simple working algorithmic code. We also really want capable and experienced engineers who know how to build and operate real systems, but do not expect grads to have any such experience -- this can be learned over time on the job once someone is working in industry, especially when supervised by senior engineers. Ability with the basics & potential to learn and become a lot more valuable gets you in the door as a junior.
A (the?) classic talk on the subject of boring technology is Dan McKinley's http://boringtechnology.club/
Another interesting read is Nygard's book "Release It!" about designing and building reliable systems, although it might be hard to understand the importance of some of these topics without first spending a few years in an organisation maintaining and operating systems and services that need to be available. https://pragprog.com/titles/mnee2/release-it-second-edition/
In terms of getting better at this without working in industry, perhaps one way could be to identify an existing open project that is relatively old and regarded as being well-engineered, stable and boring, and try to figure out how you can contribute to it.
Another way to build intuition about the importance of boring software is to gain experience maintaining and operating systems. E.g. set up your own services that run 24/7 providing value to yourself and others, then figure out what it takes to keep those services running enough of the time. Do this for enough years, every now again again some surprising failure mode will occur, and you may gain wisdom while trying to fix it or prevent it from ever reoccurring. I've personally written many useless short-term toy software projects to explore different ideas, but the hobby project that provided the best lessons in terms of building reliable software is a project that is actually continually useful to me (as a user, not as a hobbyist) so I am willing to invest ongoing time and energy operating and maintaining the software (web application hosted at home) -- over the years you need to deal with: operating system upgrades, database version upgrades, schema changes, external API changes, rare failure modes in your application code, hardware failures.
It's also quite likely that different industries & different contexts value different kinds of boringness. E.g. large organisations running web services that need to be available (popular websites, ecommerce, banking) might value technologies that increase service availability, make it cheaper to hire and train engineers to maintain, and that can be deployed onto commodity hardware. Other organisations that ship software to embedded devices that are not connected to the internet and need to run in real time might value quite different dimensions of "boringness".
> Boring here seems to mean "reliable and easily understandable"
Another way to think about this is to consider the context that the software is used in, from the perspectives of users, operators, managers. Users want the software to be reliable, support their current browser, help them do the task at hand, and not corrupt their messages / lose their rent payment / leak their credit card numbers. Operators want to get a good night's sleep without getting paged because the site has fallen over again, and when things go wrong, want to be able to draw on an existing body of technical knowledge (documentation, bug reports, known workarounds) from the community about the known failure modes and shortcomings of the technologies that are being used. Managers want it to be relatively easy and cheap to hire new people to maintain the software when the original designers and developers of the system quit for better jobs / retire / are promoted away, want the system to be relatively cheap to operate, and want the system to be relatively flexible and modifiable so it can be bent to accommodate new requirements.
> My peers are building projects with short lifespans to get into the industry, which works to get a job, but feels like starting a bad habit.
Your peers are pragmatic. When I interview people for software engineering roles, I am mainly looking for problem solving skills, some fluency with basic data structures, ability to translate idea for a solution into simple working algorithmic code. We also really want capable and experienced engineers who know how to build and operate real systems, but do not expect grads to have any such experience -- this can be learned over time on the job once someone is working in industry, especially when supervised by senior engineers. Ability with the basics & potential to learn and become a lot more valuable gets you in the door as a junior.
A (the?) classic talk on the subject of boring technology is Dan McKinley's http://boringtechnology.club/
Another interesting read is Nygard's book "Release It!" about designing and building reliable systems, although it might be hard to understand the importance of some of these topics without first spending a few years in an organisation maintaining and operating systems and services that need to be available. https://pragprog.com/titles/mnee2/release-it-second-edition/
In terms of getting better at this without working in industry, perhaps one way could be to identify an existing open project that is relatively old and regarded as being well-engineered, stable and boring, and try to figure out how you can contribute to it.
Another way to build intuition about the importance of boring software is to gain experience maintaining and operating systems. E.g. set up your own services that run 24/7 providing value to yourself and others, then figure out what it takes to keep those services running enough of the time. Do this for enough years, every now again again some surprising failure mode will occur, and you may gain wisdom while trying to fix it or prevent it from ever reoccurring. I've personally written many useless short-term toy software projects to explore different ideas, but the hobby project that provided the best lessons in terms of building reliable software is a project that is actually continually useful to me (as a user, not as a hobbyist) so I am willing to invest ongoing time and energy operating and maintaining the software (web application hosted at home) -- over the years you need to deal with: operating system upgrades, database version upgrades, schema changes, external API changes, rare failure modes in your application code, hardware failures.
It's also quite likely that different industries & different contexts value different kinds of boringness. E.g. large organisations running web services that need to be available (popular websites, ecommerce, banking) might value technologies that increase service availability, make it cheaper to hire and train engineers to maintain, and that can be deployed onto commodity hardware. Other organisations that ship software to embedded devices that are not connected to the internet and need to run in real time might value quite different dimensions of "boringness".
Saw the boring tech talk while look thru HN's search and it was great. Will read the "Release it!" book as soon as I can. I never really thought much about the idea of a my own 24/7 service but sounds like a great exercise. Going to see what projects I can do and spin up something in that light. I agree that context is important, like the organization running web services, reminds me when I worked on campus as a student web developer and was surprised that school's websites use Drupal instead of something Node based and that they were using Joyent Containers instead of Docker like most new projects do.
Thank you again for all the advice!
Thank you again for all the advice!
[deleted]
I interpret it as not writing "clever" code, as in, code that uses obscure features or otherwise not obvious logic for no good reason, making it less readable.
I wish I could give you some examples of what I mean, but I can't think of anything right now.
> I wish I could give you some examples of what I mean, but I can't think of anything right now.
I got one. I almost wrote a monstrosity the other day involving a nasty heap of reflection in order to make a program more generic and reusable. I ended up defeating half of the polymorphism and type system features of the language I was using.
In the end there was no “good way” to solve the problem thanks partially to artificial constraints, but I rewrote it so that at least one could get a reasonable idea of what the code was doing.
I got one. I almost wrote a monstrosity the other day involving a nasty heap of reflection in order to make a program more generic and reusable. I ended up defeating half of the polymorphism and type system features of the language I was using.
In the end there was no “good way” to solve the problem thanks partially to artificial constraints, but I rewrote it so that at least one could get a reasonable idea of what the code was doing.
"Clever" code reminds me of Cowboy Coding [1] where people do something similar. But I wonder if there is more to "boring" than what not to do.
[1] https://en.wikipedia.org/wiki/Cowboy_coding
[1] https://en.wikipedia.org/wiki/Cowboy_coding
'Boring' here seems to mean "reliable and easily understandable". You could search material about software testing, modularity programming, and in general best practices in coding.
In my mind it is related to KISS and suckless philosophy https://suckless.org/philosophy/
Well also the long lasting bit, use the building blocks that are sound and principles that aren't newfangled for your particular language of choice.
Well also the long lasting bit, use the building blocks that are sound and principles that aren't newfangled for your particular language of choice.
I think it's a big thing at Google as it's in the are book
https://sre.google/sre-book/simplicity/
Your basically not adopting faddy ideas and keeping code simple
https://sre.google/sre-book/simplicity/
Your basically not adopting faddy ideas and keeping code simple
> When it comes to building things that last, being boring is great. No one wants to be the first person to drive their car over a bridge built with untested techniques that the engineer thought were cool. The modern world depends on software as much as it depends on bridges, perhaps more so. Yet many programming languages add features without thinking about their impact on the maintainability of the codebase. Go is intended for building programs that last, programs that are modified by dozens of developers over dozens of years.
I'm graduating soon and noticed on campus a sense of impatience. My peers are building projects with short lifespans to get into the industry, which works to get a job, but feels like starting a bad habit. "Boring" seems fundamental for long-lasting software.
How can I learn more about "boring" code? Perhaps even lessons from outside software, to create things that last?