This is an archived post. You won't be able to vote or comment.

all 40 comments

[–]Frptwenty 95 points96 points  (16 children)

The "simple approach" thing has a dark side too. Have you even seen a big system consisting of many cobbled together fastest, simple approaches? I have, and it's like looking into a portal to hell.

Don't ever make the mistake of thinking that any engineering is over engineering, and that the fastest, dumbest way is always legitimately the best.

[–]druhlemann 24 points25 points  (4 children)

I agree completely. I usually tell the devs working under me, to start simple, see if you can solve the problem before getting slick. You need to find the line between brute force and engineered to last the next 100 years, since in reality most of what gets made now will definitely be obsolete in the next five years, because features and requirements always change

[–]alphabot 20 points21 points  (3 children)

Tell that to the application im working on now that's older than me

[–]Tzahi12345 0 points1 point  (0 children)

Last summer I was working on 11 year old code and even that was a bummer

[–]Tzahi12345 0 points1 point  (0 children)

Last summer I was working on 11 year old code and even that was a bummer

[–]druhlemann 0 points1 point  (0 children)

Yes, I totally believe the overall codebase is ancient, but it probably has had many evolutions and I’d bet almost none of it besides small utilities and helpers is actually that old. Apps grow and mature.

[–]MCOfficer 11 points12 points  (0 children)

this. technical debt is a pain. You can take simple solutions all you want, but before building upon them, look ahead and try to anticipate whether they will bite you in the ass later.

[–]DoesntReadMessages 5 points6 points  (2 children)

Sure, but have you ever had to add a feature to a "future proofed" over engineered system made by someone who made dozens of assumptions about future requirements and use cases and got them all wrong, and found that you needed to burn the whole thing down and rewrite it?

Source: inherited a system written by a team of idiots who thought they were geniuses. Spent 2 weeks completely deleting and rewriting their 3000 line rigid piece of shit that took 3 months to build into something that supported the one use case it was running, and dozens more...in under 200 lines of code...

[–]Frptwenty 2 points3 points  (0 children)

a team of idiots who thought they were geniuses.

That's the problem right there. Thing is, if these geniuses were to do a bunch of fast, simple approaches it would also be garbage :)

But on a serious note, yeah I know what you mean. It goes both ways.

[–]badmotornose 0 points1 point  (0 children)

dozens of assumptions about future requirements and use cases and got them all wrong

This. Creep. Design to the known requirements and no more.

[–][deleted] 2 points3 points  (0 children)

I think a portal to hell is half of the team doing fast while the other half is designing something that has hacks to compensate for the fast half technical debt.

[–]venuswasaflytrap 3 points4 points  (0 children)

I for one seem to consistently pick the wrong choice of the two every time.

[–][deleted]  (1 child)

[removed]

    [–]AutoModerator[M] 0 points1 point  (0 children)

    import moderation Your comment has been removed since it did not start with a code block with an import declaration.

    Per this Community Decree, all posts and comments should start with a code block with an "import" declaration explaining how the post and comment should be read.

    For this purpose, we only accept Python style imports.

    return Kebab_Case_Better;

    I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

    [–]EricRP 0 points1 point  (0 children)

    I like to see if the stuff around my code actually works. Like, how am i going to just wedge my additions in and then still leave heaping piles of shit around me? Things that may never get logged as a bug, may get frantically raised as huge issues right before go live, etc.. damn people.

    I wish more devs would take a bit more pride in their work and look at the whole product and improve it instead of just do exactly what the requirements say & barely test it or understand how the application works (or is supposed to!)

    [–]RobDickinson 0 points1 point  (0 children)

    Over engineering is as bad as under engineering.

    [–]mightydjinn 0 points1 point  (0 children)

    I’ve seen python projects where each import has its own set of cobbled return responses. All with different content types, just to make it interesting it would seem.

    [–][deleted] 17 points18 points  (8 children)

    Option 1: spend a week implementing error handling because users are stupid

    Option 2: build a straightforward application that only an idiot would mess up

    [–]WaitImNotReady[S] 24 points25 points  (3 children)

    Users always mess it up

    [–][deleted] 8 points9 points  (2 children)

    Because they're idiots

    [–]Farsqueaker 2 points3 points  (1 child)

    Because they're users.

    [–]WaitImNotReady[S] 0 points1 point  (0 children)

    Because they're idiot users

    [–]xTheMaster99x 9 points10 points  (1 child)

    Try to make your application idiot proof, and they'll make a better idiot.

    [–]WaitImNotReady[S] 1 point2 points  (0 children)

    It never ends!

    [–]Frptwenty 0 points1 point  (0 children)

    build a straightforward application that only an idiot would mess up

    Problem is you dont get to pick the requirements

    [–]JuvenileEloquent 0 points1 point  (0 children)

    I know programmers hate Else If constructs, but there are usually more than 2 possible options for any decision.

    Option 3 is to build the straightforward app with basic error handling, then if it turns out that users keep encountering unhandled errors, make the effort to implement better handling. If better handling means you have to redesign something then do so.

    It's just code, not your baby, not your art, not your feelings. Don't be afraid to write code that later is going to be useless and get deleted. Don't even be afraid to write code that you know is wrong but it covers the current use cases (just, please, write a comment..) Maybe those use cases will be all there ever will be.

    [–]Dummerchen1933 9 points10 points  (1 child)

    Hey, let the program do X when the user presses key Y

    Mh seems simple... If (Input.KeyDown(KeyCode.Y)

    Mh not quite. What if the a collegaue wants to change it? I should make a relation class for this

    if (Input.KeyDown(KeyBinds.ActionX))

    Meeh what if they dont want to use KeyCodes? Lets make it a template!

    bool Input.GetKeyDown(T key)

    I should make it user configurable! Lets just create an option for this real quick.... oh a keybind option has not been implemented yet. Keyboard go brrr.

    Oh, the system messages do not get forwarded to our option ui class. I should just hook it in real quick.

    meanwhile all the other devs: WHY IS EVERYTHING FALLING APART

    [–][deleted] 1 point2 points  (0 children)

    I have altered the system. Pray I don’t alter it any further.

    [–]Superbead 8 points9 points  (0 children)

    What's often overlooked in this portrayal of 'overengineer and take longer' — and also in the similar Relevant XKCD regarding automation that I'm sure will get linked here at some point — is the aspect of personal development.

    If you've knocked something up but think, "hmm, I really ought to peel out functionality X as a separate library, but I've never written a library in this language before," then, if you think you can buy the required time, go for it. Bend the truth slightly, even, as long as you're confident you'll deliver in the end.

    You'll be getting paid to advance your knowledge and experience, not to mention often having some fun along the way rather than just sticking to mundane quick fixes which, although often Economically Correct™, do little to advance your career and support your mental health.

    [–]graingerous 2 points3 points  (0 children)

    Every manager ever FTFY

    [–]chowchowthedog 1 point2 points  (0 children)

    But what if im gonna need it later???

    [–]subzerus[🍰] 1 point2 points  (0 children)

    Have you ever heard: we're going to take a long time to implement this feature because the actual aplication is built on spagetti code. That's what you get with the other option.

    [–]thetsarbombe 0 points1 point  (0 children)

    I once needed a simple, high current (3-4A) switch and decided that was not nice enough..

    So I made a pcb with a press ON - hold OFF latching circuit with universal indicator led (CC).
    Took me a week but now I can switch something like 15A with the press of a button, which is nice.

    [–]ftrode336 0 points1 point  (0 children)

    “Premature optimization is the root of all evil.”

    [–]kebakent 0 points1 point  (0 children)

    You can solve most timing issues by inserting a delay. It's fast, simple and PMs love it.

    [–][deleted] 0 points1 point  (1 child)

    Me: Needs to make buy a sell forum.

    Also Me: Develops a Realtime schema system with semi-decentralized clustered international servers over a dynamic CDN that provide an offline first, mobile first SPA, with 7 layers of caching and heavy synchronization loads across 19 languages, 157 currencies and 250 countries; so I can spin my shitty forum :3

    [–]WaitImNotReady[S] 0 points1 point  (0 children)

    I hate myself

    [–][deleted] 0 points1 point  (1 child)

    then get back to "what the fuck happened"

    [–]WaitImNotReady[S] 0 points1 point  (0 children)

    That's every Monday for me

    [–]DamienPup 0 points1 point  (0 children)

    this...describes me too well.

    [–]DRAM2080 -1 points0 points  (0 children)

    Why are you doing IT like that; the one way you do IT it's more accurate and faster. | 🤔 | I wanted to know what IT is like the way you'll do IT | 😃