Re:Ask HN: What practices can we use to avoid overengineerin...
by Gibbon1 on Wednesday February 06, 2019 @08:43PM
(#19102177)
> Don't pitch building a lawnmower if you just want to trim a tiny grass stem.
I'm a fan of sprint from point A to point B with shovels and and machetes'
Then think about: Where are we. What's here. Was this even worth it? Is this exactly where we need to be?
Then start working on the real path from both ends and the middle. Or not, maybe the footpath is all you need right now.
I just remember.
I hacked together GUI to run a bunch of production tests. And it was a total trashfire. And the guys in the lab ran it for two and a half years like that. With no changes.
Early in my career I saw a hardware engineer get pissed at the software guy taking months to finish the firmware. Wrote it himself in three weeks, and shipped the fucker. The code was _ugly_ and _nasty_. But it was never changed once in production.
Edit: What I mean by this is the dev process needs to be aligned with what you're doing. Sometimes big process is appropriate and sometimes/often not.
I'm a fan of sprint from point A to point B with shovels and and machetes'
Then think about: Where are we. What's here. Was this even worth it? Is this exactly where we need to be?
Then start working on the real path from both ends and the middle. Or not, maybe the footpath is all you need right now.
I just remember.
I hacked together GUI to run a bunch of production tests. And it was a total trashfire. And the guys in the lab ran it for two and a half years like that. With no changes.
Early in my career I saw a hardware engineer get pissed at the software guy taking months to finish the firmware. Wrote it himself in three weeks, and shipped the fucker. The code was _ugly_ and _nasty_. But it was never changed once in production.
Edit: What I mean by this is the dev process needs to be aligned with what you're doing. Sometimes big process is appropriate and sometimes/often not.