9 ms·

To me, this was the money quote: > You might say, “But event sourcing is so elegant! Having a SPA on top of microservices is so clean!” Sure, it can be, but no

by whack 9y ago

To me, this was the money quote: > You might say, “But event sourcing is so elegant! Having a SPA on top of microservices is so clean!” Sure, it can be, but not when you’re the person writing all ten microservices. It is that kind of additional complexity that is often so unnecessary. It's very easy to be wasteful when: 1. It's not your time that's being wasted 2. It's not your money that's being wasted One of the best learning experiences I had, was building and launching an entire application API, purely by myself, in my free-time while juggling a full-time job. It really helps you accurately evaluate the cost-benefit tradeoffs for various flavor-of-the-month technologies/methodologies, when you're the one who has to shoulder every one of those costs. I've had far too many team-leads whose assessments of these cost-benefit tradeoffs are intensely skewed by the fact that it's other people who have to work on those things, and it's other people's money that is being burnt while working on these things. We think these are technical debates, but really, it's a organizational problem. Under the right organizational structure and incentives, people are exceedingly bright at optimizing for their personal success. The principal-agent problem is a crippling handicap that hobbles every medium/large business today. The day we find better ways to solve this problem, is going to be a transformational day in the history of our civilization. https://en.wikipedia.org/wiki/Principal–agent_problem https://en.wikipedia.org/wiki/Principal–agent_problem

joaofs 9y ago
Couldn't agree more. The bandwagon effect is something also worth mentioning. Tech stacks and tools these days are branded almost as consumer products and the outcome is poorly designed systems.
- lotyrin 9y ago
  The net present value to a developer of dooming their current employer's current project by choosing an unsuitable technology which they could put on their resume to negotiate future salary (at a position they'll be moving to in, on average, months not years) is going to swamp betting on something boring but stable, completing the project, staying put and crossing their fingers for raises that outpace inflation.
  - majormajor 9y ago
    The root problem here is our hiring and interviewing system. Imagine if interviewing rewarded "look I know all this stuff about writing simple functions in Stack X" less than "yes, the project shipped, and beat its deadline, because we decided to use library Y that the devs already knew even with the acknowledged pain points, instead of bringing a new technology in just for this project. We have some less-mission critical areas where we decided to experiment with new tech, but needed something predictable here." Evaluating a senior dev based on junior-dev-esque implementation tasks instead of "does this person know how to avoid over-complicating our job?" is ludicrous. As an industry we interview to find "clever" people rather than "wise" people.
    - user5994461 9y ago
      Outside of web development, you can get a job fine without using this year framework. However, you still have to leave after a year to get more than inflation.
      - squeeeeeeeeeee 9y ago
        > you still have to leave after a year to get more than inflation This hits home. I've been in software development for quite some time (10 years), I've been with 4 employers so far (full time) and pretty much all my significant raises have come as a result of me looking for a better paying position and then leaving. I may have been unlucky (I also did not work for a really large company yet), but I feel like the "career develoment" opportunities within software engineering companies are way under the level they should be.
        reassembled 9y ago
        I think this has been the way of the tech industry, and particularly SV, for a long time now. My uncle, now passed away, started at Atari in the early 80s and hopped companies every three years until his final job with Nvidia in a fairly senior position. He stayed with Nvidia until his death a little over a year ago. Each time he switched it up he grew his salary exponentially.
- pjmlp 9y ago
  Exactly, frameworks and tools are resume driven, everyone is putting new ones as a means to sell themselves to companies, do conference talks, set up their consultancy, .... And when they move along to the new shiny thingy, those tech stacks die unless they achieved momentum beyond the usual adoption curve.
cookiecaper 9y ago
I think you're on the right track when you're saying that this isn't a technical problem. That's the most important thing to understand about the development of overwrought, top-heavy system architectures. Trying to fix this with more code is a fool's errand. As soon as you get something reasonable and good, someone will come along to distort and abuse it to serve their non-technical interests. IMO a few of the main reasons we see this plague of listless over-engineering are: a) many people don't actually know what they're doing, and they're trying to hide behind ever-shifting technical targets to obscure this fact. Sometimes this is pretty blatant, but this happens in a more subtle form with surprising frequency. Many people maintain only a very superficial interest and understanding in what's happening under the covers, so they hear promises of magic hand-waving and instantly jump to them. and b) people are forced by the principal to coop themselves up in an office for 8 hours per day, and they need to invent things to occupy their time. You could say that this is the agent not respecting the principal's investment, but it really goes both ways. Our employment model does not allow for "done", because as soon as this happens, the contributor is declared redundant and the revenue stream disappears. It's fun to brainstorm models that may not have that issue. A relatively flat/reasonable technical apparatus is needed to reason coherently about a system at all. A lot of these microservice shops are complete nightmares, and they use "microservices" as cover for "nothing is maintainable, just delete it and start over when we need to make an important change". People primarily want to use the latest stacks and make complex system architectures to gratify their vanity, in various ways: to keep their resume relevant, to be treated like a guru, and to keep up with the joneses. These are problems that stretch way outside of tech and affect everything humans do. Have other technical fields found ways of handling this sanely? What is stopping civil engineers from changing to a different concrete formulation every two weeks? Is that there is an objective physical component that can be tested, whereas software lives primarily as a manifestation of a mental problem-solving structure? Those are the answers that our field needs to look for IMO.
- majormajor 9y ago
  > and b) people are forced by the principal to coop themselves up in an office for 8 hours per day, and they need to invent things to occupy their time. You could say that this is the agent not respecting the principal's investment, but it really goes both ways. Our employment model does not allow for "done", because as soon as this happens, the contributor is declared redundant and the revenue stream disappears. It's fun to brainstorm models that may not have that issue. I think you might be overstating this part. I haven't been in many positions where if I said "hey, I finished that thing you asked me to do, and it took five fewer people and six fewer months than we thought" the response would be "ok, looks like we can fire you all now" instead of "great! get started on the next from the list of 100 things we think might be useful for the business!" + some good results at performance review time. My usual frustration is the opposite: I can't knock out my tasks as quickly as I could because I'm waiting on other teams to figure out how to add an unexpected new feature to their overengineered buzzwordy codebase. Maybe this is a high-growth vs low-growth environment type of thing, but even in more stable businesses, seems like the maintenance backlog never really empties. Just gotta make sure the bosses understand that you wouldn't fire the workers every time the shop temporarily clears - you're still going to need them for the next jobs that come in.
blablabla123 9y ago
Amen. I think the effects can be significantly lessened though under various circumstances: - highly technical boss (understands that things might backfire) - flat hierarchies (responsibility isn't delegated through layers...) - reasonable work culture with nice people But yeah, as an employee this is a question of luck, landing in the right place.
dustingetz 9y ago
What you say is all true, but its also a local maxima that we're all caught in. I think there's a critical threshold at which we could achieve accelerating good with computing instead of today's computing doing a lot of harm. What the path to that threshold is, is an interesting conversation to have.
- knieveltech 9y ago
  A few decades of observed reality suggest the path involves reversing the arrow of time. Software fucks up everything it touches in one way or another, with few meaningful gains outside of simple convenience.
  - mwcampbell 9y ago
    At the risk of going off on a tangent, your pessimism is unwarranted. Consider, first of all, that we're having this discussion on a message board with participants from all over the world. That's a meaningful benefit of software. I read both the original article and this discussion with a screen reader, because I'm visually impaired. I can also use a screen reader to read ebooks. Sure, I have enough sight that I could read regular print with a simple magnifier. But without software, my totally blind friends would have to wait for the things they want to read to be transcribed into braille, recorded, or read to them in person. This, to me, is a benefit of software that goes way beyond convenience. I could go on, but this blog post by Bertrand Meyer responds to general pessimism about software better than I could: https://bertrandmeyer.com/2013/03/12/apocalypse-no-part-1/ https://bertrandmeyer.com/2013/03/12/apocalypse-no-part-1/
    - knieveltech 9y ago
      Spend some time contemplating all of the ways that the modern surveillance state oppresses minorities, all of the drivers of income inequality (both domestically and globally), how few people actually benefit meaningfully from automation, and get back to me about how my "pessimism" is unwarranted. FFS, software has lowered the barrier to warfare so far we're bombing somewhere between five and ten (I can't even keep up) countries currently, and it isn't even generating column inches in the local paper.
Waterluvian 9y ago
Caring about those decisions even when it's not your time or money is what I think "craftsmanship" is.
drtz 9y ago
If you're building something you plan on throwing away, or won't be around to maintain, it makes perfect sense to throw things together quickly. If you're building something that will be a foundation for many future projects, however, it's worthwhile to put more thought, and thus more time, into building it. > It's not your time that's being wasted More frequently than I would like, I find myself putting a band-aid fix on something that I should have spent more time thinking through up-front. In this case it's future-me whose time I wasted by not taking my time initially.
- taurath 9y ago
  In a startup scenario, business changes can and will come in that destroy previous assumptions. Being stuck with a 1/4 finished cathedral when you now need to build a truck is both wasteful and inneficient
  - fsloth 9y ago
    Being sloppy and being fast are not the same thing. One can be fast by limiting complexity, yet provide a disciplined implementation. In an uncertain scenario, such as you described, I would say it never pays to be sloppy, but it often pays not to do anything more than is absolutely necessary for the time being.
    - he0001 9y ago
      Ah the million dollar statement. Ofc you can make something completely right, that ”race car” project but then someone says “but I want a bus” and you transform it as fast as possible to a bus and somewhere half way through someone comes along and say “why isn’t it flying”.
      - fsloth 9y ago
        I've never worked anywhere in 18 years where the goals of a project weren't at least limited to the correct 'vehicle class'. Implementation details sure can change but that's why "fast and disciplined" is good - you learn to implement the software in a manner where you understand the changes needed based on concrete principles rather than a mad dash of copy-and-pasting. By 'disciplined' I don't mean that the program fullfills the dogmatic mandates of some system development philosophy - just that the software is written on solid principles that at least the author understands.
dualogy 9y ago
What a brilliantly terse formulation of the topic complex that had me pondering for quite a while now! In some manner, "mulling over casually on-and-off" for 2 decades. > Under the right organizational structure and incentives, people are exceedingly bright at optimizing for their personal success. Optimizing organisations for converging towards such structure-and-incentives would be the money-shot, wouldn't it.. the only set-up coming to my mind proven to work (for team sizes greater than 1) are the cliche garage up-start and "small gang of well-aligned-in-skill-levels-and-obsession, ~90% of the work/design 100% under own control, product-builders". In other words, how can every small tech team feel like "early-days id Software" --- or rather, the perception of it that prevailed. > The principal-agent problem is a crippling handicap that hobbles every medium/large business today. The day we find better ways to solve this problem, is going to be a transformational day in the history of our civilization Indeed. "Medium/large" is worth repeating. Small shops need to get to medium to be able to financially and mentally afford to become some-degree-of-"wasteful". The question then becomes, why is this dynamic so predictably playing out every time that they indeed will? Is it human nature? A case of "everyone who continually succeeds in meeting their next goal eventually rises to their level of incompetence"? Is it that as soon as the adrenaline-rush of ensuring "the bacon" has actually worked, we naturally relax and become playful? With the only way to express 'playful' in a "serious setting" being to endlessly bikeshed and adopt new toys to play with, I mean "promising/proven tech to adopt and migrate/pivot to"? Remember early-Google's (maybe they still have it) "20% of the week is play-time (at least for developers)". No (or at least reduced) need to channel the urge into counterproductive role-plays of long-winded 'architectural/tech/stack/paradigm debates'. No matter how you cut it, they must have gained heaps from this arrangement not just in product prototypes like Gmail, Maps etc but probably also simply in reduced time-wasting back then. I do suspect for 99+%-software companies, the most fruitful model might turn out to be like this but with 80% devoted to the "play approach" and only 20% of the week to revisiting the concern's concerns that inform and subtly (re)direct in what problem areas to "play more". It's just a bit too radical-seeming to invest a-million-plus in, unless it's one's own millions (and possibly reserved for structures that don't primarily aim every second of every day to "exit" from their own construction).. I suspect the remaining 20% "serious" puts that aspect in the right adrenaline-driven ultra-effective no-BS 'hungry hunting mode'/context and would remain crucial so that "play" doesn't drift off into 'massaging sandcastley no-one ever asked for'..
on_and_off 9y ago
Couldn't agree more. On the mobile app I am working on, the hope is to move from dozen of Activities to a single one all MVI based. That's nice (even though it will be a nightmare to debug and optimize) but it will takes tons of engineering work for absolutely not product return. My current plan is to get the hell out of there before that.

by whack 9y ago

joaofs 9y ago

Couldn't agree more. The bandwagon effect is something also worth mentioning. Tech stacks and tools these days are branded almost as consumer products and the outcome is poorly designed systems.

lotyrin 9y ago
The net present value to a developer of dooming their current employer's current project by choosing an unsuitable technology which they could put on their resume to negotiate future salary (at a position they'll be moving to in, on average, months not years) is going to swamp betting on something boring but stable, completing the project, staying put and crossing their fingers for raises that outpace inflation.
- majormajor 9y ago
  The root problem here is our hiring and interviewing system. Imagine if interviewing rewarded "look I know all this stuff about writing simple functions in Stack X" less than "yes, the project shipped, and beat its deadline, because we decided to use library Y that the devs already knew even with the acknowledged pain points, instead of bringing a new technology in just for this project. We have some less-mission critical areas where we decided to experiment with new tech, but needed something predictable here." Evaluating a senior dev based on junior-dev-esque implementation tasks instead of "does this person know how to avoid over-complicating our job?" is ludicrous. As an industry we interview to find "clever" people rather than "wise" people.
  - user5994461 9y ago
    Outside of web development, you can get a job fine without using this year framework. However, you still have to leave after a year to get more than inflation.
    - squeeeeeeeeeee 9y ago
      > you still have to leave after a year to get more than inflation This hits home. I've been in software development for quite some time (10 years), I've been with 4 employers so far (full time) and pretty much all my significant raises have come as a result of me looking for a better paying position and then leaving. I may have been unlucky (I also did not work for a really large company yet), but I feel like the "career develoment" opportunities within software engineering companies are way under the level they should be.
      - reassembled 9y ago
        I think this has been the way of the tech industry, and particularly SV, for a long time now. My uncle, now passed away, started at Atari in the early 80s and hopped companies every three years until his final job with Nvidia in a fairly senior position. He stayed with Nvidia until his death a little over a year ago. Each time he switched it up he grew his salary exponentially.
pjmlp 9y ago
Exactly, frameworks and tools are resume driven, everyone is putting new ones as a means to sell themselves to companies, do conference talks, set up their consultancy, .... And when they move along to the new shiny thingy, those tech stacks die unless they achieved momentum beyond the usual adoption curve.

cookiecaper 9y ago

I think you're on the right track when you're saying that this isn't a technical problem. That's the most important thing to understand about the development of overwrought, top-heavy system architectures. Trying to fix this with more code is a fool's errand. As soon as you get something reasonable and good, someone will come along to distort and abuse it to serve their non-technical interests. IMO a few of the main reasons we see this plague of listless over-engineering are: a) many people don't actually know what they're doing, and they're trying to hide behind ever-shifting technical targets to obscure this fact. Sometimes this is pretty blatant, but this happens in a more subtle form with surprising frequency. Many people maintain only a very superficial interest and understanding in what's happening under the covers, so they hear promises of magic hand-waving and instantly jump to them. and b) people are forced by the principal to coop themselves up in an office for 8 hours per day, and they need to invent things to occupy their time. You could say that this is the agent not respecting the principal's investment, but it really goes both ways. Our employment model does not allow for "done", because as soon as this happens, the contributor is declared redundant and the revenue stream disappears. It's fun to brainstorm models that may not have that issue. A relatively flat/reasonable technical apparatus is needed to reason coherently about a system at all. A lot of these microservice shops are complete nightmares, and they use "microservices" as cover for "nothing is maintainable, just delete it and start over when we need to make an important change". People primarily want to use the latest stacks and make complex system architectures to gratify their vanity, in various ways: to keep their resume relevant, to be treated like a guru, and to keep up with the joneses. These are problems that stretch way outside of tech and affect everything humans do. Have other technical fields found ways of handling this sanely? What is stopping civil engineers from changing to a different concrete formulation every two weeks? Is that there is an objective physical component that can be tested, whereas software lives primarily as a manifestation of a mental problem-solving structure? Those are the answers that our field needs to look for IMO.

majormajor 9y ago
> and b) people are forced by the principal to coop themselves up in an office for 8 hours per day, and they need to invent things to occupy their time. You could say that this is the agent not respecting the principal's investment, but it really goes both ways. Our employment model does not allow for "done", because as soon as this happens, the contributor is declared redundant and the revenue stream disappears. It's fun to brainstorm models that may not have that issue. I think you might be overstating this part. I haven't been in many positions where if I said "hey, I finished that thing you asked me to do, and it took five fewer people and six fewer months than we thought" the response would be "ok, looks like we can fire you all now" instead of "great! get started on the next from the list of 100 things we think might be useful for the business!" + some good results at performance review time. My usual frustration is the opposite: I can't knock out my tasks as quickly as I could because I'm waiting on other teams to figure out how to add an unexpected new feature to their overengineered buzzwordy codebase. Maybe this is a high-growth vs low-growth environment type of thing, but even in more stable businesses, seems like the maintenance backlog never really empties. Just gotta make sure the bosses understand that you wouldn't fire the workers every time the shop temporarily clears - you're still going to need them for the next jobs that come in.

blablabla123 9y ago

Amen. I think the effects can be significantly lessened though under various circumstances: - highly technical boss (understands that things might backfire) - flat hierarchies (responsibility isn't delegated through layers...) - reasonable work culture with nice people But yeah, as an employee this is a question of luck, landing in the right place.

dustingetz 9y ago

What you say is all true, but its also a local maxima that we're all caught in. I think there's a critical threshold at which we could achieve accelerating good with computing instead of today's computing doing a lot of harm. What the path to that threshold is, is an interesting conversation to have.

knieveltech 9y ago
A few decades of observed reality suggest the path involves reversing the arrow of time. Software fucks up everything it touches in one way or another, with few meaningful gains outside of simple convenience.
- mwcampbell 9y ago
  At the risk of going off on a tangent, your pessimism is unwarranted. Consider, first of all, that we're having this discussion on a message board with participants from all over the world. That's a meaningful benefit of software. I read both the original article and this discussion with a screen reader, because I'm visually impaired. I can also use a screen reader to read ebooks. Sure, I have enough sight that I could read regular print with a simple magnifier. But without software, my totally blind friends would have to wait for the things they want to read to be transcribed into braille, recorded, or read to them in person. This, to me, is a benefit of software that goes way beyond convenience. I could go on, but this blog post by Bertrand Meyer responds to general pessimism about software better than I could: https://bertrandmeyer.com/2013/03/12/apocalypse-no-part-1/ https://bertrandmeyer.com/2013/03/12/apocalypse-no-part-1/
  - knieveltech 9y ago
    Spend some time contemplating all of the ways that the modern surveillance state oppresses minorities, all of the drivers of income inequality (both domestically and globally), how few people actually benefit meaningfully from automation, and get back to me about how my "pessimism" is unwarranted. FFS, software has lowered the barrier to warfare so far we're bombing somewhere between five and ten (I can't even keep up) countries currently, and it isn't even generating column inches in the local paper.

Waterluvian 9y ago

Caring about those decisions even when it's not your time or money is what I think "craftsmanship" is.

drtz 9y ago

If you're building something you plan on throwing away, or won't be around to maintain, it makes perfect sense to throw things together quickly. If you're building something that will be a foundation for many future projects, however, it's worthwhile to put more thought, and thus more time, into building it. > It's not your time that's being wasted More frequently than I would like, I find myself putting a band-aid fix on something that I should have spent more time thinking through up-front. In this case it's future-me whose time I wasted by not taking my time initially.

taurath 9y ago
In a startup scenario, business changes can and will come in that destroy previous assumptions. Being stuck with a 1/4 finished cathedral when you now need to build a truck is both wasteful and inneficient
- fsloth 9y ago
  Being sloppy and being fast are not the same thing. One can be fast by limiting complexity, yet provide a disciplined implementation. In an uncertain scenario, such as you described, I would say it never pays to be sloppy, but it often pays not to do anything more than is absolutely necessary for the time being.
  - he0001 9y ago
    Ah the million dollar statement. Ofc you can make something completely right, that ”race car” project but then someone says “but I want a bus” and you transform it as fast as possible to a bus and somewhere half way through someone comes along and say “why isn’t it flying”.
    - fsloth 9y ago
      I've never worked anywhere in 18 years where the goals of a project weren't at least limited to the correct 'vehicle class'. Implementation details sure can change but that's why "fast and disciplined" is good - you learn to implement the software in a manner where you understand the changes needed based on concrete principles rather than a mad dash of copy-and-pasting. By 'disciplined' I don't mean that the program fullfills the dogmatic mandates of some system development philosophy - just that the software is written on solid principles that at least the author understands.

dualogy 9y ago

What a brilliantly terse formulation of the topic complex that had me pondering for quite a while now! In some manner, "mulling over casually on-and-off" for 2 decades. > Under the right organizational structure and incentives, people are exceedingly bright at optimizing for their personal success. Optimizing organisations for converging towards such structure-and-incentives would be the money-shot, wouldn't it.. the only set-up coming to my mind proven to work (for team sizes greater than 1) are the cliche garage up-start and "small gang of well-aligned-in-skill-levels-and-obsession, ~90% of the work/design 100% under own control, product-builders". In other words, how can every small tech team feel like "early-days id Software" --- or rather, the perception of it that prevailed. > The principal-agent problem is a crippling handicap that hobbles every medium/large business today. The day we find better ways to solve this problem, is going to be a transformational day in the history of our civilization Indeed. "Medium/large" is worth repeating. Small shops need to get to medium to be able to financially and mentally afford to become some-degree-of-"wasteful". The question then becomes, why is this dynamic so predictably playing out every time that they indeed will? Is it human nature? A case of "everyone who continually succeeds in meeting their next goal eventually rises to their level of incompetence"? Is it that as soon as the adrenaline-rush of ensuring "the bacon" has actually worked, we naturally relax and become playful? With the only way to express 'playful' in a "serious setting" being to endlessly bikeshed and adopt new toys to play with, I mean "promising/proven tech to adopt and migrate/pivot to"? Remember early-Google's (maybe they still have it) "20% of the week is play-time (at least for developers)". No (or at least reduced) need to channel the urge into counterproductive role-plays of long-winded 'architectural/tech/stack/paradigm debates'. No matter how you cut it, they must have gained heaps from this arrangement not just in product prototypes like Gmail, Maps etc but probably also simply in reduced time-wasting back then. I do suspect for 99+%-software companies, the most fruitful model might turn out to be like this but with 80% devoted to the "play approach" and only 20% of the week to revisiting the concern's concerns that inform and subtly (re)direct in what problem areas to "play more". It's just a bit too radical-seeming to invest a-million-plus in, unless it's one's own millions (and possibly reserved for structures that don't primarily aim every second of every day to "exit" from their own construction).. I suspect the remaining 20% "serious" puts that aspect in the right adrenaline-driven ultra-effective no-BS 'hungry hunting mode'/context and would remain crucial so that "play" doesn't drift off into 'massaging sandcastley no-one ever asked for'..

on_and_off 9y ago

Couldn't agree more. On the mobile app I am working on, the hope is to move from dozen of Activities to a single one all MVI based. That's nice (even though it will be a nightmare to debug and optimize) but it will takes tons of engineering work for absolutely not product return. My current plan is to get the hell out of there before that.