5 ms·

Lately I've been thinking about the airplane design analogy for writing software. Supposedly (possibly apocryphally) Bill Gates said that measuring software dev

by dkarl 2y ago

Lately I've been thinking about the airplane design analogy for writing software. Supposedly (possibly apocryphally) Bill Gates said that measuring software development progress by lines of code written was like measuring aircraft design progress by weight. I think the analogy is a valuable one. On an airplane, you might look for places where the airframe is stronger than it needs to be. If you can save material there, it'll be not just cheaper but lighter and more efficient. If the weight savings improves the flight characteristics of the aircraft, or if allows for the addition of safety features elsewhere, it might improve safety as well. This is a really hard conversation to have in software, because when people think they can make something better with a lot of extra code, a lot of times they'll just do it, even if they know that other people think it's unnecessary. They put in the extra time on their own responsibility, thinking that the only downside is the initial work to write the code, and once it's done, it becomes an asset. It sucks to tell them that I'd rather not have it, that I'd rather have the easy version they could have done in an hour. I give in way more often than I'd like to.

DanielHB 2y ago
The hardest part of keeping software sane is saying to no requirements. I like to say two things about software: Code is a liability The best code is no code
- umvi 2y ago
  The fastest code is code that never runs because it doesn't exist
  - fuzztester 2y ago
    it's also the most correct *, as well as the cheapest ;) * "every line is a potential bug"
yjftsjthsd-h 2y ago
> This is a really hard conversation to have in software, because when people think they can make something better with a lot of extra code, a lot of times they'll just do it, even if they know that other people think it's unnecessary. They put in the extra time on their own responsibility, thinking that the only downside is the initial work to write the code, and once it's done, it becomes an asset. It sucks to tell them that I'd rather not have it, that I'd rather have the easy version they could have done in an hour. I give in way more often than I'd like to. I feel like that's a perfect case for making software more modular? Whether it's runtime plugins or compile-time options (with stable APIs and keeping things separate), it's possible to let people who want a feature have it without affecting anyone else.
- Retric 2y ago
  Modularity isn’t free. It’s useful for many things, but assuming it’s inherently valuable is how you end up with enterprise bloat. Programming languages are inherently flexible, however when you have 2 features and a configuration option to select between them you now have 3 features.
  - yjftsjthsd-h 2y ago
    > Programming languages are inherently flexible, however when you have 2 features and a configuration option to select between them you now have 3 features. Which is a good argument for separating things into plugins: If you have 1 stable API/ABI and 100 plugins, you have 1 feature.
    - Retric 2y ago
      If you’re writing the software and the plugins you have 101 features and likely a bunch of complicated integrations between plugins or when people change them. It’s only really useful if you’re getting 3rd parties to support plugins written by them.
- mystified5016 2y ago
  Now you need to pay someone to implement a solution for automatically packaging and distributing your plugins. You have extra complexity on every project to manage pulling dependencies. Someone needs to maintain all those packages and the infrastructure to serve them. I'm doing this right now for my company. Starting from zero automation it's taken probably half my time these last few months. Every project needs individual care. Some projects require major refactors to use the new libraries instead of their own implementation. I have to secure our releases so we don't leak credentials, I have to secure the GitLab server, we have a half dozen new accounts and keys to keep track of forever. That kind of modularity really isn't free at all, in any sense.
codewench 2y ago
Conversely, it's far better to have a slightly more verbose section of code that is immediately readable than a super slick one-liner that like two people can parse. Maintainability is, in my opinion, just as important as other considerations when writing code. And often the more verbose approach is composed of simpler steps, meaning bugs can be easier to spot during code reviews
- dkarl 2y ago
  Agreed. For readability, ignoring DRY, my hierarchy of preference is: 1. One reasonable line of code 2. Several lines of plain code 3. A function call, moving the implementation elsewhere 4. A gnarly one-liner (The tough part about this is drawing the line between 1 & 4.)

by dkarl 2y ago

DanielHB 2y ago

The hardest part of keeping software sane is saying to no requirements. I like to say two things about software: Code is a liability The best code is no code

umvi 2y ago
The fastest code is code that never runs because it doesn't exist
- fuzztester 2y ago
  it's also the most correct *, as well as the cheapest ;) * "every line is a potential bug"

yjftsjthsd-h 2y ago

> This is a really hard conversation to have in software, because when people think they can make something better with a lot of extra code, a lot of times they'll just do it, even if they know that other people think it's unnecessary. They put in the extra time on their own responsibility, thinking that the only downside is the initial work to write the code, and once it's done, it becomes an asset. It sucks to tell them that I'd rather not have it, that I'd rather have the easy version they could have done in an hour. I give in way more often than I'd like to. I feel like that's a perfect case for making software more modular? Whether it's runtime plugins or compile-time options (with stable APIs and keeping things separate), it's possible to let people who want a feature have it without affecting anyone else.

Retric 2y ago
Modularity isn’t free. It’s useful for many things, but assuming it’s inherently valuable is how you end up with enterprise bloat. Programming languages are inherently flexible, however when you have 2 features and a configuration option to select between them you now have 3 features.
- yjftsjthsd-h 2y ago
  > Programming languages are inherently flexible, however when you have 2 features and a configuration option to select between them you now have 3 features. Which is a good argument for separating things into plugins: If you have 1 stable API/ABI and 100 plugins, you have 1 feature.
  - Retric 2y ago
    If you’re writing the software and the plugins you have 101 features and likely a bunch of complicated integrations between plugins or when people change them. It’s only really useful if you’re getting 3rd parties to support plugins written by them.
mystified5016 2y ago
Now you need to pay someone to implement a solution for automatically packaging and distributing your plugins. You have extra complexity on every project to manage pulling dependencies. Someone needs to maintain all those packages and the infrastructure to serve them. I'm doing this right now for my company. Starting from zero automation it's taken probably half my time these last few months. Every project needs individual care. Some projects require major refactors to use the new libraries instead of their own implementation. I have to secure our releases so we don't leak credentials, I have to secure the GitLab server, we have a half dozen new accounts and keys to keep track of forever. That kind of modularity really isn't free at all, in any sense.

codewench 2y ago

Conversely, it's far better to have a slightly more verbose section of code that is immediately readable than a super slick one-liner that like two people can parse. Maintainability is, in my opinion, just as important as other considerations when writing code. And often the more verbose approach is composed of simpler steps, meaning bugs can be easier to spot during code reviews

dkarl 2y ago
Agreed. For readability, ignoring DRY, my hierarchy of preference is: 1. One reasonable line of code 2. Several lines of plain code 3. A function call, moving the implementation elsewhere 4. A gnarly one-liner (The tough part about this is drawing the line between 1 & 4.)