Hacker News new | ask | show | jobs
by trommlp 897 days ago
I don't know all the reasons individual developers would want a more complicated piece of software. Might be to show off, yes, or to learn about a new technology to the detriment of those developers that come after and the Ops people who will have to maintain it. Or they genuinely believe complicated is better.

But the one thing that ultimately adds a lot of unneeded complexity to basically every software project at my work are requirements. That kind of requirement that nobody thought of when the project kicked off. And this kind of requirement that a few months later everyone realizes nobody actually needed. And that you possibly remove after a while. But in the meantime this feature influenced your entire data model or worse.

This is the point where your previously fun work turns into a slog for the duration of said project. Well at least we can still have fun with our hobby projects!

1 comments

When I look back, I see my "overengineering everything" era as a phase, a live lesson to be learnt. I overengineered a couple of things massively because I didn't know what lied ahead and that helped me, but then I learnt that it's harmful as the "default mode of programming".

As I understood how performance worked, what's maintainability and minimalism (as a general concept), the code I write became minimal and simpler.

Currently I'm working in a mode which can be called "overgrow and extend". I start with the most simplistic code which satisfies the design and my requirements, then refactor any part which cracks under the design to satisfy the requirements without being hacky. This philosophy works like a charm for me. Coupled with my "needless comments", getting back into context and extending/maintaining the code is easier than ever.

I even started to finish and deploy my personal projects. It's that effective for me.

Now I'm learning live documentation, which allows me to write the documentation of the things I'm working on simultaneously. When things finish I also have a workable documentation as a result.

You are of course right that developers have to learn to keep things simple and that skill comes from overengineering stuff. Maybe I have been overly negative on my original comment. As long as it's just a "phase" the long-term benefits of going through that phase should be much higher than the short-term costs to your org.

Good on you for having success with your personal projects!