It is different if you are working on a team or as an individual. On a team it's important to build ways for people to work autonomously because once that's done the team as a whole will have more throughput. For an individual those same separations might be a drag on productivity. Regardless, careful consideration for what is _needed_ at every step of the way is important. Extreme Programming is worth a look.
Ask HN: How to avoid over-engineering software design for future use cases?
201–210 of 258 posts
Re: Ask HN: How to avoid over-engineering software design for future use cases?
#202The junior developer sees a pattern and thinks why not make this a bit more generic so it handles similar cases. Oh but these cases fit a larger pattern.. and eventually you'll have written yourself an entire framework. This is very valuable, for the experience. Not for the framework, which will never be used. But you should go through it. The mid-career developer knows this from experience and sticks to the minimum…
Most people never make it to your definition of senior engineer
[deleted]
Re: Ask HN: How to avoid over-engineering software design for future use cases?
#203Sometimes the source of the problem is political: one trying to make a more general framework to deprecate another team, or to avoid being deprecated by generalizing in a slightly different direction.
How do people “defend” that in big Corp?
Boat the technical roadmap and requirements with fantasy future features, so they can say “well that framework doesn’t support X, and our framework will support X”. It doesn’t matter whether X is useful in practice or not, since the managers don’t always have the power to make that call.
Re: Ask HN: How to avoid over-engineering software design for future use cases?
#204Earlier quoted context omitted.
I did, across different roles in two well known teams. As I said, there are exceptions, and the hiring bar has been dropping a lot in the recent years.
Well, they haven’t hired me yet, so either I’m terrible, or the hiring bar is just completely arbitrary.
In all large companies the people involved in an interview are a tiny fraction of the whole workforce.
Most of the time it's people from the team that is hiring and one or two "guests" from other teams (but usually working in the same building).
Managers also have plenty of power to influence the decision, therefore keeping a very uniform hiring bar is really difficult. (But no, it's not "completely arbitrary")
Also, I wrote that the bar dropped a lot, to the point of shifting all employees level up by one, but this does not mean that the company hires 90% of the candidates.
If a team was hiring 1 candidate every 1000 screened resumes and now it's 1 in 100 it's a whopping 10x change... but that doesn't make you a terrible engineer!
Re: Ask HN: How to avoid over-engineering software design for future use cases?
#205Read this post a month ago about future welcome architecture and found it quite practical (with some philosophical musings though), hope it helps - https://www.twowaystolearn.com/posts/future-welcome-architec...
Re: Ask HN: How to avoid over-engineering software design for future use cases?
#206This tendency has been noted since at least the Manhattan Project, described by none other than Richard Feynman. The prescription for oneself is pretty simple - just say no! It is relatively easy to catch yourself whenever you think about some improvement that's irrelevant to delivering so long as you have convinced yourself that you need to wholeheartedly focus on delivering.
It is more difficult to persuade others not to over-engineer. I have tried and failed many times to do so. In fact, if you try too hard you may just make them hate their job. Folks get into software development for a whole host of reasons and only one of them is shipping. They may not be satisfied with a job where they funnel requests from a PM directly into code with little creative input. I'm not sure I can give good advice on this front, other than to look out for certain red flags during hiring.
Re: Ask HN: How to avoid over-engineering software design for future use cases?
#207I am a firm believer that the most important superpower a software engineer and their team should have is refactoring. By refactoring what I mean is continually revisiting the architecture of your code, identifying common functionality, better organisation of code, better abstractions. The right decisions for your codebase change as it evolves and so you need to keep reexamining these (implicit) decisions. Continuous…
This. I did not decide to do this, but over time I refactor things. As I gain experience doing that, I realize I have started to write "refactorable code" (you heard it hear first. In JavaScript land (I'm a fan by the way) this is inevitable. JQuery, React, hooks, context, promises, async, ES6, on and on. The churn in JavaScript is painful, as many people note, the code I started with is now both smaller, clearer and…
I was lucky to work with a great and experienced SW engineer early in my career. Among other things we were working on a Bluetooth stack of approximately 1 million lines of C.
I had assumed in my naivety that as I got more experienced was that I would get better at doing things right 'first time' and wouldn't need to keep going back and fiddling with code I'd already written because it now wasn't quite right. What I learned instead was that he spent at least 50% of his time re-working existing code.
There are two important things. The right design changes as you add more code. You learn more about what the right design should be as your work on the code.
You're never going to get it right first time. So instead concentrate on continuously making it better.
Re: Ask HN: How to avoid over-engineering software design for future use cases?
#208This is an interesting question. Intuitively, there should be some sweet spot, some golden middle between going 100% ad-hoc and writing for the future with no real use cases. I'm not sure if anyone in this world knows where is this sweet spot though. In 2017 I started https://wordsandbuttons.online/ as an experiment in unchitecture. There are no generic things there whatsoever. There are no dependencies, no libraries…
Thanks for sharing wordsandbuttons, it is full of very interesting content, which is, after all, the only thing that humans consume from it. It is a very good answer to OP.
Furthermore, the site is very satisfying to navigate, specially with the dev console's network tab on. I'd just love if the whole web was like this again.
Keep up the good work!
Re: Ask HN: How to avoid over-engineering software design for future use cases?
#209Earlier quoted context omitted.
> My dopamine levels [0] skyrocket when I visualize making some component generic, or future proof. I think I've successfully rewired that impulse in myself now, at least partially. I do get that feeling from imagining great systems, but I also get that dopamine hit from deleting old stuff and simplifying things as much as possible. We can ditch compatibility for API v8? Awesome, I just made my code smaller and we ca…
Honestly I think this may be a component: besides code shame (my code is bad and I don't want other people to see it) a lot of programmers also feel protective of their code. They want it to last forever, a paean to their skills. Writing simple code to throw away and refactor feels like a failure -- it should be perfect and eternal.
I totally understand the sentiment of writing elegant code that lasts forever, but I think developers need to manage their expectations a little better.
If you're writing foundational code for an operating system, then yeah, whatever you write is going to stick around for a while. (Which means you need to be a LOT more careful about what you write.)
If you're writing code for a mobile app or website, expect your code to get thrown out in a few months due to shifting requirements. I'm sure the Facebook app has been completely rewritten more than once, since they switched to React Native at one point.
If you're writing a JavaScript library, expect your code to be replaced next week. :D
Re: Ask HN: How to avoid over-engineering software design for future use cases?
#210This tendency has been noted since at least the Manhattan Project, described by none other than Richard Feynman. The prescription for oneself is pretty simple - just say no! It is relatively easy to catch yourself whenever you think about some improvement that's irrelevant to delivering so long as you have convinced yourself that you need to wholeheartedly focus on delivering. It is more difficult to persuade others…
> The prescription for oneself is pretty simple - just say no! It is relatively easy to catch yourself whenever you think about some improvement that's irrelevant to delivering so long as you have convinced yourself that you need to wholeheartedly focus on delivering.
That's fairly true if you intend a monomaniacal focus on delivery and you are dealing with improvements that are truly irrelevant.
If other concerns like code hygiene have nonzero value, and/or if improvements have some potential relevance to delivery but are not unmistakably essential, then things get more interesting. Doing the least work possible to get by with a work item may be good for initial velocity but at long term cost.
It's probably easier in an environment where things like code hygiene expectations and review standards are well-known from a combination of express standards and team experience, but not all environments are like that.