Stop future-proofing software
medium.com
Stop future-proofing software
1–10 of 63 posts
Re: Stop future-proofing software
#2[deleted]
Re: Stop future-proofing software
#3YAGNI is, as ever, pretty good advice. It’s hard to follow, it’s always tempting to ignore.
Re: Stop future-proofing software
#4The simpler your codebase is, the easier it is to adjust to fulfill a different purpose.
I think this is the most important sentence in the article. I've worked on a few extremely abstracted and horribly-indirect codebases that happened to be so very flexible and extensible in exactly all the wrong directions, so much that it made it much harder to change in the way that was actually required.
Re: Stop future-proofing software
#5Medium is conducive to inserting stupid images in the middle of the posts.
Re: Stop future-proofing software
#6Medium is conducive to inserting stupid images in the middle of the posts.
Could you please start posting more substantively?
Re: Stop future-proofing software
#7> We need to use an inheritance based design for our types,
> despite composition being a much easier alternative, because
> after 5 years of codebase growth, it will make our lives
> easier.
And a equally future-proofy statement:
"We need to contort our code to avoid our implementation language's inheritance features to instead use composition because after 5 years of codebase growth it will make our lives easier"
There's a reason why the GoF says "prefer composition over inheritance" and then spends half the book covering inheritance.
Re: Stop future-proofing software
#8As Martin Fowler correctly explains, YAGNI is primarily about end-user features, not the flexibility of the code and the toolchain. If you don't keep your tech stack (code, infrastructure, people) flexible, then iterative development becomes impossible. The assumption behind YAGNI is that 'you can't predict requirements accurately'. Which is true, so don't build them ahead of time. However, the same assumption requires you to be flexible, modular, etc.
Specific example from TFA: distributed app vs. large server. A distributed app might give you better scalability, which you might not need because large servers are cheap. However, a distributed app also forces you to think about state, so if you screw something up and have to fix it middle of the day, you can BG deploy the app instead of having a 4 minute outage. It forces you to modularize the logic and think about interfaces, so if you need to add, remove or change functionality then it'll likely be faster.
Etc.
What this article forgets to say is: "Stop future-proofing your software if you are still looking for a good product-market fit. As soon as you know what your business is going to be, make sure your technology stack is flexible."
Re: Stop future-proofing software
#9> We need to use a kubernetes & docker based solution for our infrastructure, despite a single large server being a much easier alternative
It's a half-truth that one doesn't have to do it from the very beginning.
You don't have to set up a whole cluster where a single host suffices for a long while. You do have to plan that your project may eventually become big enough to require a cluster - and consider doing yourself some design favors here and there to make that transition easier. Or knowing that you're going to spend a while redesigning stuff, while being pressed by the growth.
I mean, I've regretted not doing some design assumptions (e.g. about storage) from the start more than once or twice.
Re: Stop future-proofing software
#10I thought this was really spot on. The point about the glorification of people working on really hard problems at scale. I just read The Google SRE book and while there are definitely lessons I can use in the company for which I work (~5 devs), it definitely isn't a straightforward "do what worked there".
I couldn't find hard numbers from the Bureau of Labor Statistics, but this Stackoverflow survey [0] from 2016 points out that 50% of developers work at companies with less than 100 employees (that's employees, not developers). So many many software jobs are at smaller companies. Why don't we hear from them about their trials and tribulations?
Here are some ideas I've had (off the cuff), would love to hear other thoughts.
1. Big companies invent the future because they have the resources to do so. That wisdom then gets rolled out often in the form of software (Hadoop, k8s, React).
2. Small companies are boring. They are still struggling with product market fit or are stable and boring. They are not sexy, especially if they aren't growing quickly or are a services company.
3. Bigger companies have a bigger platform to announce work and/or support people to write and speak. Software they develop touches more folks.
4. Smaller companies are not doing anything interesting to the wider development community. They are focused on niche problems that aren't really interesting.
5. Folks at smaller companies don't write/speak as much.
6. We are hearing from smaller companies, just not as much/it's categorized as 'startups'.
7. Consultants, who tend to do a lot of proselytizing of new software trends, work for larger companies because "that's where the money is".
8. The scale of small business is such that software quality doesn't matter as much.
I don't really know what the reason is. I've primarily worked for small companies my entire career and I think the impact that software can have on a small business is transformative and well worth writing about (as I have for years and years [1]).
[0]: https://insights.stackoverflow.com/survey/2016#company-size