7 ms·

Opinion-Driven Design

113 points by diegopacheco 5y ago

afarrell 5y ago
Yes. If you’re going to write software, know the “Why” behind the software and follow through on that intent. This is especially true for internal software like a framework — the marketing department won’t be there to keep reminding you why your customers are your customers if your customers are your colleagues. The intent can change. For example, your intent might change from “Hey I just noticed I can do this thing and want to explore why it might be useful” to “this framework helps a programmer avoid missing data dependencies”.
l0b0 5y ago
Definitely. Only make something configurable if you know there are people you want to use the software who will use different values for that configuration. Infinite flexibility equals infinite complexity.
- hinkley 5y ago
  Infinite complexity doesn’t really phase people. But pointing out that infinite flexibility means an infinite test surface, sometimes gives people pause.
- noduerme 5y ago
  But can you know how people will use your software? I think it's better to plan for the unexpected, and just make sure each individual part doesn't affect the others. For example, CSS basically offers infinite flexibility in a graphics model, often with unforeseen run-on consequences within the document. People use it in all kinds of crazy ways. But it's not a big deal, because it doesn't usually interfere with app logic on any deeper level. A narrower case to make could be, it's actually good to offer tons of options, just make them all, like, optional and isolated.
  - mannykannot 5y ago
    > But can you know how people will use your software? This is one of the many areas where good judgement matters, and where good judgement cannot be bought through a collection of judgement-free rules. One reasonable rule of thumb, however, is that something intended to be general-purpose (like CSS) will probably need lots of options.
jimkleiber 5y ago
> Instead of a tool shaped specifically for their needs, the framework's core developers often wanted flexibility: they dreamt of open sourcing their framework and it growing popular, so it needed to handle as many cases as possible to reach as wide an audience as possible. This helped to clarify so much for me. I have done this so frequently not just with software that I've built, but websites, products, even romantic relationships. I can start to imagine different cases (and edge cases) and then eventually get stuck in an infinite loop trying to make it work for everyone. One of the latest examples: trying to price a SaaS or ebook for friends/customers across different geographies and economic classes. After reading this post, I felt relieved, maybe because of this line: > So I started to prefer opinion-driven design when I realised that flexibility comes with a price that is often not worth paying. Helped me realize just how much energy I've spent trying to keep options open.
- kqr 5y ago
  Sure. The only way to create quality software at a reasonable cost is to start out solving a really small, specific use case, get that implementation robust, performant, and with few defects. Then expand into another small, specific use case. This was known already by the pioneering software engineers in the 1960's. There are two things pulling us away from it: - Business naturally wants to tick off as many boxes as possible on a feature list. This leads to software that purports to do many things, but do them all quite shittily. Like Deming, I believe this is a swindle to acquire many customers in the short term, but screwing them over and losing them long-term. - There's some sense in trying to generalise the code, too: sometimes that leads to cleaner and more readable code. Often more easily testable code. Well, maybe. It's a very difficult point of judgment, and I personally get it wrong quite often.
  - dgb23 5y ago
    Those small things need to communicate with each other at some point, so you build stuff around them. You end up with the same complexity regardless, just organized differently. Now, I don’t disagree with you. Maybe this organization is very beneficial. Typically systems with small, specific pieces that talk over a generic, well designed interface do work well. HTTP, Unix Pipes, currency, mail, bees... the whole becomes adaptive and accommodating. This kind of design is discussed in the latter half of Elements of Clojure by Zachary Tellman. https://elementsofclojure.com/ https://elementsofclojure.com/ What I like about this, to come back to the article, is that it gives a clear sense of where generality should reside.
rualca 5y ago
Is "opinion-driven design" an attempt to reinvent YAGNI and to try to pass it off the concept as a brand new discovery? https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it
- stepbeek 5y ago
  I guess that "there's nothing new under the sun". I used to get annoyed by instances like this where it feels close enough to be essentially a rebrand but now I view it as a posistive thing. If there's someone out there that never really understood YAGNI but ODD clicks then that's great.
- meheleventyone 5y ago
  It’s top-down versus bottom-up. YAGNI is about individual decisions. This is about mindset. Naming it Opinion-Driven Design is a bit cringey and clouds the actual intent though. But a call for more opinionated software is a good thing IMO.
  - rualca 5y ago
    > YAGNI is about individual decisions. This is about mindset. Is there any difference at all?
    - meheleventyone 5y ago
      Yeah I usually see YAGNI as a response to some specific feature or idea a programmer has. Where as the idea that you should start by building opinionated rather than very general software is much more about what you're building in the first instance and has implications outside of the resulting code. YAGNI boils up and "opinionated software" bubbles down. They're complementary though.
      - rualca 5y ago
        Calling them complementary is quite the stretch. You've only talked about YAGNI twice, with one time throwing a "opinionated" label without any reason. I mean, let's be honest here: "you ain't gonna need it". That's what YAGNI stands for, and represents. That's what you say to anyone who claims "but it would be far more flexible if...". It's YAGNI, no matter how much makeup you want to slap onto it.
stepbeek 5y ago
My rails experience has mainly been dabbling with some admiration from afar, but I've liked that the criticism levied against it at times is that it's a framework for building basecamp. That's why it's good! It's been built with a purpose and it turns out that purpose is close enough to others (like building shopify) that it's useful for lots of companies. I'd much rather use a tool like that than one that shallowly appealed to every hypothetical user.
BlackFly 5y ago
> Instead of a tool shaped specifically for their needs, the framework's core developers often wanted flexibility: they dreamt of open sourcing their framework and it growing popular, so it needed to handle as many cases as possible to reach as wide an audience as possible. The other way, which I have personally seen, is that the core developers fight the pressures that lead to generality, but this has one of two side effects. Either non-core developers grow frustrated as they increasingly encounter problems that the framework handles poorly (or not at all) and need to choose solutions to fit the tool, or they just don't use that framework in the cases where it doesn't fit well. There are strong incentives to never choose the second option since it is either a design choice that makes the tool fit poorly or a difficult to describe edge case that requires a different solution. As an analogy, all problems can be solved with X language, so why would you ever need Y language? A framework is something approaching a domain specific language, so I feel like the analogy is appropriate. People naturally fall into this trap of "one framework to rule them all" and what starts off lean and well suited to particular tasks ends up unwieldy and bloated because people aren't willing to pick up a different tool instead of just generalizing the tool they are using. Yet, the expression "one size fits all" naturally leads people to instead think that the fit is going to be ugly on most people nonetheless. So if you want opinion driven development to succeed, you need to tell people what problems you are trying to make easier to solve and admit that there are similar problems for which the framework fits poorly and maybe another opinionated framework is a better choice. You need people that are willing to work with a wide variety of technologies.
locallost 5y ago
I actually prefer it when maintainers do that because I don't really need e.g. 4 different ways to call a function or a method, and the more there are, the harder it is to find the stuff I want in the documentation.
valenterry 5y ago
I think most of the criticism comes from using frameworks instead of libraries. Libraries give more freedom and take a bit more effort to be wired together, but if you know what you are doing (which can be a big if) then they are more flexible and hence productive in the long-term. Essentially, you could say that the "opioniated framework" that the author talks about is just a library that does one thing well.
- ItsMonkk 5y ago
  This is my take as well. If you are building a framework and its sub-components are frameworks that act on their own behalves, you better build exactly what you need in an opinionated style. But if you are building a framework and its sub-components are libraries, those libraries can be as general as possible, and your framework can then call those libraries in just the way that you need to. The library strategy will always out-compete in the end if you can handle it properly. If you try to do it half-way like these developers did, you will be ruined just like they found. Reposting from a similar comment yesterday - > Frameworks are easier to setup initially, but they do not scale. Why is it that Microsoft Windows has 13 different dialog generations? Because each is a framework on top of a framework on top of a framework. It's amazing that they can even get that done. > When the 2 UNIX devs were in a basement building UNIX and were able to out-compete Multics[0], they did it because they were building libraries that could talk with each-other using pipes around the boundary. Applications that communicate based on input-output with no internal state behave just like pure functions do. Pure functions compose. When Linus built git in 10 days, he was able to do this because the core idea of git isn't actually that much work. The framework is built out of composable blocks that neatly come together as libraries. Microsoft's TFS Source Control is a framework that acts on your behalf and therefore the bigger the project gets, you need n^2 people to work on it. [0]: https://www.youtube.com/watch?v=3Ea3pkTCYx4 https://www.youtube.com/watch?v=3Ea3pkTCYx4, thanks to this HN comment(https://news.ycombinator.com/item?id=27494671 https://news.ycombinator.com/item?id=27494671) for this reference.
noduerme 5y ago
I built my own framework that I've used for a dozen or so apps since 2005. It started in SQL/PHP/HTML/JS/Air and slowly migrated project by project, class by class, to SQL/Node/Typescript. Some of the utility classes are still almost exact transcriptions. Every project introduces new challenges and use cases the framework wasn't designed for. I try to add the ones to the core that I think will be helpful down the road, and keep a repository of other elements I can look up just in case. Whenever I take a project, I often find myself building in "what if" scenarios - e.g. what if the client asks for some further functionality down the road. I view my job as a programmer as trying to think of these things the client might not yet have conceived of, and leaving room for them in future iterations. I'll bring them up to the client and if they don't need them, I'll often write them in anyway. From the POV of putting out a concise, open-source package, I wouldn't do that. There's no need to expose half-baked functionality. But for myself, for my own work, I'll at least make a code stub and some notes every time I think of one of those things where an extra argument could be added, or extra functionality could branch off. At least half the time, clients come back years later asking for some functionality I stubbed, and I at least know where to look for it. If it seems useful enough, I merge it into the core. So I don't think it's a bad impulse to try to think of every edge case. That's a great impulse. You just don't have to write the code for each one right now unless you think they'll impact daily operations. But if you were to lose the urge to do it, I'd argue you'd be a lesser programmer.
- midrus 5y ago
  I'm sorry for anyone that has ended up having to maintain any project made with any of these custom frameworks.
  - noduerme 5y ago
    I certainly understand that from a team / larger organization perspective. But since I'm the de facto maintainer of these apps for the rest of my life, it's quite nice to have written everything myself and know the strengths and weaknesses intimately, from the UI to the database. And it wouldn't be so bad for someone to take over. I maintain contingency "if I get hit by a bus" documents for each active app, accessible to the client and containing keys, links to source code, and helpful pointers. The framework has evolved to be readable, relatively simple in practice, and well documented. For what I charge, it's been a good deal for both me and the clients - mostly smaller businesses with custom needs that can be iterated over time. When Salesforce reps come knocking, trying to scare them about the dangers of technical debt or future migration costs for custom platforms, it's pretty much like, "we'll switch eventually if we have to, but why would we pay you guys three times more to migrate and manage it, when we can already request new features whenever we want?" The truth is, no one will ever have to maintain them, because when I'm gone they'll just rebuild from scratch; they've already gotten their money's worth over the years of operation.
arpa 5y ago
problem with opinions is that they can be (and usually are) ignorant.
conor_f 5y ago
This is something I've been trying to work on recently. My current work is very piecemeal and after spending months trying to simplify processes and make generic tools/systems, I realized that using one current tool that will do 80% of the job now as opposed to spending two weeks to make a bespoke tool that may never be used again (at least without modification) is a far better option. I think that accepting that some things are going to be bespoke or if not they will have limitations and just moving on with them is a key skill to develop.
erellsworth 5y ago
This hits home. I often find myself spending extra time on something to make it more flexible. Often that flexibility is never needed. However, this is partly driven by the reverse experience. Many times I've built something with very little flexibility only to have to rebuild it or at least make a lot of changes to enable some new use case. I can't count how many times I've asked a product owner "will this ever need to be able to do X?" and been assured that it would not, only to have X be requested months or even weeks later. When I'm building something I focus on getting it to meet the immediate requirements, but when there are opportunities to make something more flexible/configurable/reusable without hours of extra work I take them. It's a constant balancing act.
parasubvert 5y ago
I spent a significant amount of my career working on opinionated software (Cloud Foundry), which still is used by larger companies to give devs a Heroku-like experience on their own clouds, that was steamrolled in the market by unopinionated, rather complicated, “one framework to rule them all” software (Kubernetes), which isn’t even directly targeted at the same problem space, it’s a more of an elegant set of lower level building blocks. 15 years ago, the opposite happened: working on unopinionated, complicated Java Enterprise Edition and app servers, that got partially steamrolled by Ruby On Rails (opinionated). That didn’t quite last in wide popularity but for a moment it was huge, and led to good reactions in the Java community like Spring Boot. The moral of the story is that the market wants what it wants when it comes to “platform” software, or software that you use to help build other software: sometimes it’s opinionated software (like Apple and iOS), other times it is relatively unopinionated (like Android). It almost always is a fight between camps. There are many factors at play, not only developer desire: what outcomes does this software lead to, and who does it benefit? What new problems does the software create? These all have an impact on the reaction in the broader market.
- rc_hackernews 5y ago
  Why do you think that is? In regards to Cloud Foundry being steamrolled by Kubernetes. There's not a day that goes by where I'm using the "current stack", i.e. K8S, Terraform, etc., and not wish I was using Heroku or something Heroku-like instead.
  - parasubvert 5y ago
    Kubernetes isn’t focused on solving specific end-user problems, it focuses on a community and a set of lower level computer science problems. The community and openness to extend itself to nearly every use case in distributed or networked computing is its strength. The CNCF’s ecosystem map shows this: there is a strong supply of options. This then drives a deep FOMO in tech consumers. In the community, from my POV anyway, the fact that Kube lacks the end-user experience of Heroku is irrelevant: what matters is how problems are solved: in the Kubernetes Way, or not at all. Some day developers may get their “cf push” or Heroku “git push”, built in Kubernetes, but it must be done “the right way” (no one knows what that is until they see it) to be accepted by the community and thus standardized. There are attempts at this today such as CNCF’s pack/buildpacks, Knative, or Openshift’s S2I… but none of that really has critical mass. The Heroku experience may never happen, but there’s a lot of money being spent to give it a shot. Kubernetes is more than software, it is a movement. It is trying to drive a standard architecture of how to build and run distributed software with a set of (mostly) elegant design patterns and principals. The YAML overload is a temporary side effect of limited scope: the endgame is that every piece of server software is manageable as a CRD with an operator, and the greater Kubernetes API ecosystem subsumes all categories of cloud and server software. It reminds me of past major tech waves like Java or Windows 95 or the Web itself: it sucks a lot of oxygen out of the conversation for a decade or so, and solves some problems while creating new ones.

113 points by diegopacheco 5y ago

Yes. If you’re going to write software, know the “Why” behind the software and follow through on that intent. This is especially true for internal software like a framework — the marketing department won’t be there to keep reminding you why your customers are your customers if your customers are your colleagues. The intent can change. For example, your intent might change from “Hey I just noticed I can do this thing and want to explore why it might be useful” to “this framework helps a programmer avoid missing data dependencies”.

l0b0 5y ago

Definitely. Only make something configurable if you know there are people you want to use the software who will use different values for that configuration. Infinite flexibility equals infinite complexity.

hinkley 5y ago
Infinite complexity doesn’t really phase people. But pointing out that infinite flexibility means an infinite test surface, sometimes gives people pause.
noduerme 5y ago
But can you know how people will use your software? I think it's better to plan for the unexpected, and just make sure each individual part doesn't affect the others. For example, CSS basically offers infinite flexibility in a graphics model, often with unforeseen run-on consequences within the document. People use it in all kinds of crazy ways. But it's not a big deal, because it doesn't usually interfere with app logic on any deeper level. A narrower case to make could be, it's actually good to offer tons of options, just make them all, like, optional and isolated.
- mannykannot 5y ago
  > But can you know how people will use your software? This is one of the many areas where good judgement matters, and where good judgement cannot be bought through a collection of judgement-free rules. One reasonable rule of thumb, however, is that something intended to be general-purpose (like CSS) will probably need lots of options.

jimkleiber 5y ago

kqr 5y ago
Sure. The only way to create quality software at a reasonable cost is to start out solving a really small, specific use case, get that implementation robust, performant, and with few defects. Then expand into another small, specific use case. This was known already by the pioneering software engineers in the 1960's. There are two things pulling us away from it: - Business naturally wants to tick off as many boxes as possible on a feature list. This leads to software that purports to do many things, but do them all quite shittily. Like Deming, I believe this is a swindle to acquire many customers in the short term, but screwing them over and losing them long-term. - There's some sense in trying to generalise the code, too: sometimes that leads to cleaner and more readable code. Often more easily testable code. Well, maybe. It's a very difficult point of judgment, and I personally get it wrong quite often.
- dgb23 5y ago
  Those small things need to communicate with each other at some point, so you build stuff around them. You end up with the same complexity regardless, just organized differently. Now, I don’t disagree with you. Maybe this organization is very beneficial. Typically systems with small, specific pieces that talk over a generic, well designed interface do work well. HTTP, Unix Pipes, currency, mail, bees... the whole becomes adaptive and accommodating. This kind of design is discussed in the latter half of Elements of Clojure by Zachary Tellman. https://elementsofclojure.com/ https://elementsofclojure.com/ What I like about this, to come back to the article, is that it gives a clear sense of where generality should reside.

rualca 5y ago

Is "opinion-driven design" an attempt to reinvent YAGNI and to try to pass it off the concept as a brand new discovery? https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it

stepbeek 5y ago
I guess that "there's nothing new under the sun". I used to get annoyed by instances like this where it feels close enough to be essentially a rebrand but now I view it as a posistive thing. If there's someone out there that never really understood YAGNI but ODD clicks then that's great.
meheleventyone 5y ago
It’s top-down versus bottom-up. YAGNI is about individual decisions. This is about mindset. Naming it Opinion-Driven Design is a bit cringey and clouds the actual intent though. But a call for more opinionated software is a good thing IMO.
- rualca 5y ago
  > YAGNI is about individual decisions. This is about mindset. Is there any difference at all?
  - meheleventyone 5y ago
    Yeah I usually see YAGNI as a response to some specific feature or idea a programmer has. Where as the idea that you should start by building opinionated rather than very general software is much more about what you're building in the first instance and has implications outside of the resulting code. YAGNI boils up and "opinionated software" bubbles down. They're complementary though.
    - rualca 5y ago
      Calling them complementary is quite the stretch. You've only talked about YAGNI twice, with one time throwing a "opinionated" label without any reason. I mean, let's be honest here: "you ain't gonna need it". That's what YAGNI stands for, and represents. That's what you say to anyone who claims "but it would be far more flexible if...". It's YAGNI, no matter how much makeup you want to slap onto it.

stepbeek 5y ago

My rails experience has mainly been dabbling with some admiration from afar, but I've liked that the criticism levied against it at times is that it's a framework for building basecamp. That's why it's good! It's been built with a purpose and it turns out that purpose is close enough to others (like building shopify) that it's useful for lots of companies. I'd much rather use a tool like that than one that shallowly appealed to every hypothetical user.

BlackFly 5y ago

> Instead of a tool shaped specifically for their needs, the framework's core developers often wanted flexibility: they dreamt of open sourcing their framework and it growing popular, so it needed to handle as many cases as possible to reach as wide an audience as possible. The other way, which I have personally seen, is that the core developers fight the pressures that lead to generality, but this has one of two side effects. Either non-core developers grow frustrated as they increasingly encounter problems that the framework handles poorly (or not at all) and need to choose solutions to fit the tool, or they just don't use that framework in the cases where it doesn't fit well. There are strong incentives to never choose the second option since it is either a design choice that makes the tool fit poorly or a difficult to describe edge case that requires a different solution. As an analogy, all problems can be solved with X language, so why would you ever need Y language? A framework is something approaching a domain specific language, so I feel like the analogy is appropriate. People naturally fall into this trap of "one framework to rule them all" and what starts off lean and well suited to particular tasks ends up unwieldy and bloated because people aren't willing to pick up a different tool instead of just generalizing the tool they are using. Yet, the expression "one size fits all" naturally leads people to instead think that the fit is going to be ugly on most people nonetheless. So if you want opinion driven development to succeed, you need to tell people what problems you are trying to make easier to solve and admit that there are similar problems for which the framework fits poorly and maybe another opinionated framework is a better choice. You need people that are willing to work with a wide variety of technologies.

locallost 5y ago

I actually prefer it when maintainers do that because I don't really need e.g. 4 different ways to call a function or a method, and the more there are, the harder it is to find the stuff I want in the documentation.

valenterry 5y ago

I think most of the criticism comes from using frameworks instead of libraries. Libraries give more freedom and take a bit more effort to be wired together, but if you know what you are doing (which can be a big if) then they are more flexible and hence productive in the long-term. Essentially, you could say that the "opioniated framework" that the author talks about is just a library that does one thing well.

ItsMonkk 5y ago
This is my take as well. If you are building a framework and its sub-components are frameworks that act on their own behalves, you better build exactly what you need in an opinionated style. But if you are building a framework and its sub-components are libraries, those libraries can be as general as possible, and your framework can then call those libraries in just the way that you need to. The library strategy will always out-compete in the end if you can handle it properly. If you try to do it half-way like these developers did, you will be ruined just like they found. Reposting from a similar comment yesterday - > Frameworks are easier to setup initially, but they do not scale. Why is it that Microsoft Windows has 13 different dialog generations? Because each is a framework on top of a framework on top of a framework. It's amazing that they can even get that done. > When the 2 UNIX devs were in a basement building UNIX and were able to out-compete Multics[0], they did it because they were building libraries that could talk with each-other using pipes around the boundary. Applications that communicate based on input-output with no internal state behave just like pure functions do. Pure functions compose. When Linus built git in 10 days, he was able to do this because the core idea of git isn't actually that much work. The framework is built out of composable blocks that neatly come together as libraries. Microsoft's TFS Source Control is a framework that acts on your behalf and therefore the bigger the project gets, you need n^2 people to work on it. [0]: https://www.youtube.com/watch?v=3Ea3pkTCYx4 https://www.youtube.com/watch?v=3Ea3pkTCYx4, thanks to this HN comment(https://news.ycombinator.com/item?id=27494671 https://news.ycombinator.com/item?id=27494671) for this reference.

noduerme 5y ago

I built my own framework that I've used for a dozen or so apps since 2005. It started in SQL/PHP/HTML/JS/Air and slowly migrated project by project, class by class, to SQL/Node/Typescript. Some of the utility classes are still almost exact transcriptions. Every project introduces new challenges and use cases the framework wasn't designed for. I try to add the ones to the core that I think will be helpful down the road, and keep a repository of other elements I can look up just in case. Whenever I take a project, I often find myself building in "what if" scenarios - e.g. what if the client asks for some further functionality down the road. I view my job as a programmer as trying to think of these things the client might not yet have conceived of, and leaving room for them in future iterations. I'll bring them up to the client and if they don't need them, I'll often write them in anyway. From the POV of putting out a concise, open-source package, I wouldn't do that. There's no need to expose half-baked functionality. But for myself, for my own work, I'll at least make a code stub and some notes every time I think of one of those things where an extra argument could be added, or extra functionality could branch off. At least half the time, clients come back years later asking for some functionality I stubbed, and I at least know where to look for it. If it seems useful enough, I merge it into the core. So I don't think it's a bad impulse to try to think of every edge case. That's a great impulse. You just don't have to write the code for each one right now unless you think they'll impact daily operations. But if you were to lose the urge to do it, I'd argue you'd be a lesser programmer.

midrus 5y ago
I'm sorry for anyone that has ended up having to maintain any project made with any of these custom frameworks.
- noduerme 5y ago
  I certainly understand that from a team / larger organization perspective. But since I'm the de facto maintainer of these apps for the rest of my life, it's quite nice to have written everything myself and know the strengths and weaknesses intimately, from the UI to the database. And it wouldn't be so bad for someone to take over. I maintain contingency "if I get hit by a bus" documents for each active app, accessible to the client and containing keys, links to source code, and helpful pointers. The framework has evolved to be readable, relatively simple in practice, and well documented. For what I charge, it's been a good deal for both me and the clients - mostly smaller businesses with custom needs that can be iterated over time. When Salesforce reps come knocking, trying to scare them about the dangers of technical debt or future migration costs for custom platforms, it's pretty much like, "we'll switch eventually if we have to, but why would we pay you guys three times more to migrate and manage it, when we can already request new features whenever we want?" The truth is, no one will ever have to maintain them, because when I'm gone they'll just rebuild from scratch; they've already gotten their money's worth over the years of operation.

arpa 5y ago

problem with opinions is that they can be (and usually are) ignorant.

conor_f 5y ago

This is something I've been trying to work on recently. My current work is very piecemeal and after spending months trying to simplify processes and make generic tools/systems, I realized that using one current tool that will do 80% of the job now as opposed to spending two weeks to make a bespoke tool that may never be used again (at least without modification) is a far better option. I think that accepting that some things are going to be bespoke or if not they will have limitations and just moving on with them is a key skill to develop.

erellsworth 5y ago

This hits home. I often find myself spending extra time on something to make it more flexible. Often that flexibility is never needed. However, this is partly driven by the reverse experience. Many times I've built something with very little flexibility only to have to rebuild it or at least make a lot of changes to enable some new use case. I can't count how many times I've asked a product owner "will this ever need to be able to do X?" and been assured that it would not, only to have X be requested months or even weeks later. When I'm building something I focus on getting it to meet the immediate requirements, but when there are opportunities to make something more flexible/configurable/reusable without hours of extra work I take them. It's a constant balancing act.

parasubvert 5y ago

I spent a significant amount of my career working on opinionated software (Cloud Foundry), which still is used by larger companies to give devs a Heroku-like experience on their own clouds, that was steamrolled in the market by unopinionated, rather complicated, “one framework to rule them all” software (Kubernetes), which isn’t even directly targeted at the same problem space, it’s a more of an elegant set of lower level building blocks. 15 years ago, the opposite happened: working on unopinionated, complicated Java Enterprise Edition and app servers, that got partially steamrolled by Ruby On Rails (opinionated). That didn’t quite last in wide popularity but for a moment it was huge, and led to good reactions in the Java community like Spring Boot. The moral of the story is that the market wants what it wants when it comes to “platform” software, or software that you use to help build other software: sometimes it’s opinionated software (like Apple and iOS), other times it is relatively unopinionated (like Android). It almost always is a fight between camps. There are many factors at play, not only developer desire: what outcomes does this software lead to, and who does it benefit? What new problems does the software create? These all have an impact on the reaction in the broader market.

rc_hackernews 5y ago
Why do you think that is? In regards to Cloud Foundry being steamrolled by Kubernetes. There's not a day that goes by where I'm using the "current stack", i.e. K8S, Terraform, etc., and not wish I was using Heroku or something Heroku-like instead.
- parasubvert 5y ago
  Kubernetes isn’t focused on solving specific end-user problems, it focuses on a community and a set of lower level computer science problems. The community and openness to extend itself to nearly every use case in distributed or networked computing is its strength. The CNCF’s ecosystem map shows this: there is a strong supply of options. This then drives a deep FOMO in tech consumers. In the community, from my POV anyway, the fact that Kube lacks the end-user experience of Heroku is irrelevant: what matters is how problems are solved: in the Kubernetes Way, or not at all. Some day developers may get their “cf push” or Heroku “git push”, built in Kubernetes, but it must be done “the right way” (no one knows what that is until they see it) to be accepted by the community and thus standardized. There are attempts at this today such as CNCF’s pack/buildpacks, Knative, or Openshift’s S2I… but none of that really has critical mass. The Heroku experience may never happen, but there’s a lot of money being spent to give it a shot. Kubernetes is more than software, it is a movement. It is trying to drive a standard architecture of how to build and run distributed software with a set of (mostly) elegant design patterns and principals. The YAML overload is a temporary side effect of limited scope: the endgame is that every piece of server software is manageable as a CRD with an operator, and the greater Kubernetes API ecosystem subsumes all categories of cloud and server software. It reminds me of past major tech waves like Java or Windows 95 or the Web itself: it sucks a lot of oxygen out of the conversation for a decade or so, and solves some problems while creating new ones.