8 ms·

> engineers go extreme in designing things/code for future cases which are not yet known They're afraid. Fear: If I don't plan for all these use cases, they w

by mabbo 6y ago

> engineers go extreme in designing things/code for future cases which are not yet known They're afraid. Fear: If I don't plan for all these use cases, they will be impossible! I will look foolish for not anticipating them. So let's give into that fear and over-architect just to be safe. A bit of the 'condom' argument applies: better to have it and not need it than to need it and not have it. But the reality is that if your design doesn't match the future needs really well, you're going to have to refactor anyway. Hint: there will always be a future need you didn't anticipate! Software is a living organism that we shape and evolve over time. Shopify was a snowboard store, Youtube was a dating website, and Slack was a video game. So my answer: relentlessly cut design features you don't need. Then relentlessly refactor your code when you discover you do need them. And don't be afraid of doing either of those things because it turns out they're both fun challenges. The best you can do is to try to ensure your design doesn't make it really hard to do anything you know or suspect you'll need in the future. Just don't start building what no one has asked for yet.

theshrike79 6y ago
Also: have a framework in place, which supports worry-free refactoring. Comprehensive Unit/Integration tests, a robust type-system, pick whatever suits your style. It's a lot easier to refactor stuff when you don't have to worry about breaking something hard to debug with a big code change.
- mcv 6y ago
  Unit tests are absolutely fantastic during refactoring. I once had to rewrite a piece of code where nobody really knew what it did or what it had to do, and the original author just made some guesses about the intention. I started out by writing unit tests for everything, which became my handhold and documentation for what the system originally did. Then I started reorganising the code into a more structured and more readable form, without changing the functionality, as proven by my unit tests. Then I started asking domain experts what exactly it should do, unit tests in hand, asking if these answers were correct. If they weren't, I changed the unit test, and then changed the code to match. Surprisingly painless for something that by all reasonable standards was a terrible mess.
  - theshrike79 6y ago
    You invented the same refactoring technique Michael Feathers suggests in his book[1]. You write tests to document the current state of the legacy software and then start slowly changing it. Great book BTW, should be on a top10 must read list for software developers. (#1 will always be Peopleware[2]) [1] https://www.goodreads.com/book/show/44919.Working_Effectively_with_Legacy_Code https://www.goodreads.com/book/show/44919.Working_Effectivel... [2] https://www.goodreads.com/book/show/67825.Peopleware https://www.goodreads.com/book/show/67825.Peopleware
    - Aeolun 6y ago
      Peopleware is great, but seeing that it was written more than 30 years ago, also completely pointless. All the advice that book gives is ignored by literally every leader I’ve ever met. Our CIO was regaling us with the story about how they were going to change our office today, make it more open, fancy like Google or Facebook, free desk. But when I asked if they’d considered dealing with the noise issues we were having, no, no they hadn’t considered that. It just blows my mind. I just really wanted to ask them what the hell they thought they were doing modifying the office layout without asking the people who need to work there.
  - antris 6y ago
    I would argue that having a robust type system and some (not too many) end-to-end tests for your software makes unit testing almost completely useless overhead.
    - smabie 6y ago
      Conventional type systems don't really help you when your code is pretty much just taking in vectors/matrices of floats and returning vectors/matrices of floats.
      - antris 6y ago
        You are correct, however that's a niche use case that would warrant using a non-conventional type system. Conventional type systems are mostly for just dumping a bunch of strings and integers to and from a database and formatting them neatly.
flak48 6y ago
>> engineers go extreme in designing things/code for future cases which are not yet known >They're afraid. In many companies (think FAANG), engineers, especially senior engineers are incentivized/forced to show fancy design docs as part of the annual appraisal process. The more complicated the design, the more 'foresight', the better. If it sounds kind of ridiculous (TPS reports from Office Space anyone?) it is. But on the other hand, taking a bit less cynical look, the more massive a company gets, the more the voices which demand objectivity in all these promotion/bonus multiplier processes. So a kind of obsession about such weird 'measurable' metrics gradually builds up in the name of objectivity. And as soon as there are metrics, you can bet everyone in the system will do their best to game them (it only makes too much sense to do so). And thus you end up with over engineered systems all over the place. A lot of the 'not-invented-here, let's reinvent it' style culture also develops similarly - you have too many smart people in a room where the work is just not that demanding. Even if you were to get over your personal existential crisis (why am I writing yet another crud app?!), if you're the type that wants to see a promotion every other year, your're forced to invent work this way.
- pydry 6y ago
  I think it's a bit more than a desire to show "fancy design docs" or metric gaming. I've seen a lot of engineers prioritize fixing as yet hypothetical future problems over problems that are burning them right now even when there is no need for design docs and no metrics to game. I think some problems are just seen as sexier than others.
  - flak48 6y ago
    For sure. I just wanted to shed a light on some unfortunate external pressures faced by a subset of engineers, which contributes to this problem. Didn't meant to come across as cynical.
- danielheath 6y ago
  People who do this get promoted because overengineering results in the manager getting more headcount. My solution was to work someplace that can’t afford to waste money on bullshit. Has worked well so far.
yonl 6y ago
What I have realized over past few years, organising code for future is a function of a characteristic of an engineer. I have noticed people who are extra organized in real life, who keeps every single file in a right directories after download tend to have inclination for prematured code refactoring for future use. If these guys become code architect then i end up doing so many unnecessary things. The fundamental assumption of the refactoring gets changed very fast and the code needs to be rewritten for the majority of the cases. From a company level I find the instructions are clear, mostly holding the same contract between services as long as possible and less schema change. Its the engineer with subjective idea of perfect code / supporting future work makes it even more complex
- marcus_holmes 6y ago
  I've seen this tendency in other areas. There are travellers who plan everything, afraid of encountering a situation that they haven't planned for. And there are travellers who trust in their ability to cope with any situation. As the GP says, this is about fear. Fear that if you don't plan for it now, you won't be able to deal with it if it happens. Or in architecture terms, fear that your system will be faced with a requirement that it can't cover. Trying to plan for every eventuality is usually wasted effort. Better to build robustly, and trust in your ability to adapt.
cynusx 6y ago
This is actually one of the lessons I had to learn the hard way. Solving for the future makes things unnecessarily complicated and even if that future arrives it will have been code debt and not/poorly maintained because literally nobody cares if it works or not. Don't do this and solve only for the problems you have now or are about to start in the next 2 sprints. edit: and make refactoring acceptable and part of your engineering culture so you do it often

by mabbo 6y ago

theshrike79 6y ago

Also: have a framework in place, which supports worry-free refactoring. Comprehensive Unit/Integration tests, a robust type-system, pick whatever suits your style. It's a lot easier to refactor stuff when you don't have to worry about breaking something hard to debug with a big code change.

mcv 6y ago
Unit tests are absolutely fantastic during refactoring. I once had to rewrite a piece of code where nobody really knew what it did or what it had to do, and the original author just made some guesses about the intention. I started out by writing unit tests for everything, which became my handhold and documentation for what the system originally did. Then I started reorganising the code into a more structured and more readable form, without changing the functionality, as proven by my unit tests. Then I started asking domain experts what exactly it should do, unit tests in hand, asking if these answers were correct. If they weren't, I changed the unit test, and then changed the code to match. Surprisingly painless for something that by all reasonable standards was a terrible mess.
- theshrike79 6y ago
  You invented the same refactoring technique Michael Feathers suggests in his book[1]. You write tests to document the current state of the legacy software and then start slowly changing it. Great book BTW, should be on a top10 must read list for software developers. (#1 will always be Peopleware[2]) [1] https://www.goodreads.com/book/show/44919.Working_Effectively_with_Legacy_Code https://www.goodreads.com/book/show/44919.Working_Effectivel... [2] https://www.goodreads.com/book/show/67825.Peopleware https://www.goodreads.com/book/show/67825.Peopleware
  - Aeolun 6y ago
    Peopleware is great, but seeing that it was written more than 30 years ago, also completely pointless. All the advice that book gives is ignored by literally every leader I’ve ever met. Our CIO was regaling us with the story about how they were going to change our office today, make it more open, fancy like Google or Facebook, free desk. But when I asked if they’d considered dealing with the noise issues we were having, no, no they hadn’t considered that. It just blows my mind. I just really wanted to ask them what the hell they thought they were doing modifying the office layout without asking the people who need to work there.
- antris 6y ago
  I would argue that having a robust type system and some (not too many) end-to-end tests for your software makes unit testing almost completely useless overhead.
  - smabie 6y ago
    Conventional type systems don't really help you when your code is pretty much just taking in vectors/matrices of floats and returning vectors/matrices of floats.
    - antris 6y ago
      You are correct, however that's a niche use case that would warrant using a non-conventional type system. Conventional type systems are mostly for just dumping a bunch of strings and integers to and from a database and formatting them neatly.

flak48 6y ago

>> engineers go extreme in designing things/code for future cases which are not yet known >They're afraid. In many companies (think FAANG), engineers, especially senior engineers are incentivized/forced to show fancy design docs as part of the annual appraisal process. The more complicated the design, the more 'foresight', the better. If it sounds kind of ridiculous (TPS reports from Office Space anyone?) it is. But on the other hand, taking a bit less cynical look, the more massive a company gets, the more the voices which demand objectivity in all these promotion/bonus multiplier processes. So a kind of obsession about such weird 'measurable' metrics gradually builds up in the name of objectivity. And as soon as there are metrics, you can bet everyone in the system will do their best to game them (it only makes too much sense to do so). And thus you end up with over engineered systems all over the place. A lot of the 'not-invented-here, let's reinvent it' style culture also develops similarly - you have too many smart people in a room where the work is just not that demanding. Even if you were to get over your personal existential crisis (why am I writing yet another crud app?!), if you're the type that wants to see a promotion every other year, your're forced to invent work this way.

pydry 6y ago
I think it's a bit more than a desire to show "fancy design docs" or metric gaming. I've seen a lot of engineers prioritize fixing as yet hypothetical future problems over problems that are burning them right now even when there is no need for design docs and no metrics to game. I think some problems are just seen as sexier than others.
- flak48 6y ago
  For sure. I just wanted to shed a light on some unfortunate external pressures faced by a subset of engineers, which contributes to this problem. Didn't meant to come across as cynical.
danielheath 6y ago
People who do this get promoted because overengineering results in the manager getting more headcount. My solution was to work someplace that can’t afford to waste money on bullshit. Has worked well so far.

yonl 6y ago

What I have realized over past few years, organising code for future is a function of a characteristic of an engineer. I have noticed people who are extra organized in real life, who keeps every single file in a right directories after download tend to have inclination for prematured code refactoring for future use. If these guys become code architect then i end up doing so many unnecessary things. The fundamental assumption of the refactoring gets changed very fast and the code needs to be rewritten for the majority of the cases. From a company level I find the instructions are clear, mostly holding the same contract between services as long as possible and less schema change. Its the engineer with subjective idea of perfect code / supporting future work makes it even more complex

marcus_holmes 6y ago
I've seen this tendency in other areas. There are travellers who plan everything, afraid of encountering a situation that they haven't planned for. And there are travellers who trust in their ability to cope with any situation. As the GP says, this is about fear. Fear that if you don't plan for it now, you won't be able to deal with it if it happens. Or in architecture terms, fear that your system will be faced with a requirement that it can't cover. Trying to plan for every eventuality is usually wasted effort. Better to build robustly, and trust in your ability to adapt.

cynusx 6y ago

This is actually one of the lessons I had to learn the hard way. Solving for the future makes things unnecessarily complicated and even if that future arrives it will have been code debt and not/poorly maintained because literally nobody cares if it works or not. Don't do this and solve only for the problems you have now or are about to start in the next 2 sprints. edit: and make refactoring acceptable and part of your engineering culture so you do it often