Many of these practices are popularized by Google/Facebook/Amazon but don't make sense for a company with 100 or even 1,000 people. I try to focus on whether a practice will solve a concrete problem we're facing. Switching from Hadoop to Spark was clearly a good idea for our team, even though it required learning a new stack, but there isn't a strong reason to switch to Flink or start using Haskell. Agile makes sense…
Ask HN: Are we overcomplicating software development?
311–320 of 378 posts
Re: Ask HN: Are we overcomplicating software development?
#312Many of these practices are popularized by Google/Facebook/Amazon but don't make sense for a company with 100 or even 1,000 people. I try to focus on whether a practice will solve a concrete problem we're facing. Switching from Hadoop to Spark was clearly a good idea for our team, even though it required learning a new stack, but there isn't a strong reason to switch to Flink or start using Haskell. Agile makes sense…
Re: Ask HN: Are we overcomplicating software development?
#313Though perhaps it's considered a component of 2), one could add Docker/containerization. I've watched folks spend weeks and weeks getting Docker setup for a service that probably didn't need to be containerized at all. And then once it's Dockerized, introspection/debugging/etc... seem to become much more difficult.
Re: Ask HN: Are we overcomplicating software development?
#314Earlier quoted context omitted.
Generally claiming that a person is doing the method wrong when the method brings no percieved benefits raises a red flag on the general applicability and value of the methodology itself on the problem the person is trying to solve. There is no one true way to organize development of software and generally shoehorning dogma without proof of value is counterproductive.
Are you really can stand for hours at the standup meeting? :-) Standup daily meeting must be short and focused. Moreover, standup meeting is for developers only. No project manager, no customer, no QA team. Just developers talking about their problems. Everything else deserves it own separate, hour long meeting once a week or two.
Re: Ask HN: Are we overcomplicating software development?
#315Many of these practices are popularized by Google/Facebook/Amazon but don't make sense for a company with 100 or even 1,000 people. I try to focus on whether a practice will solve a concrete problem we're facing. Switching from Hadoop to Spark was clearly a good idea for our team, even though it required learning a new stack, but there isn't a strong reason to switch to Flink or start using Haskell. Agile makes sense…
> TDD is good for fast feedback in some domains,...... It hears like, "IDE is good for fast feedback in some domains. " If someone saying that IDE is only suitable for GUI application but not the software he is writing, he probably means that "look at me, I am the old school tough guy." It's about the people dislike the tool but nothing about the domain.
Re: Ask HN: Are we overcomplicating software development?
#316Usability needs to be applied to more than just the end user experience: but the entire SDLC experience.
Re: Ask HN: Are we overcomplicating software development?
#317Many of these practices are popularized by Google/Facebook/Amazon but don't make sense for a company with 100 or even 1,000 people. I try to focus on whether a practice will solve a concrete problem we're facing. Switching from Hadoop to Spark was clearly a good idea for our team, even though it required learning a new stack, but there isn't a strong reason to switch to Flink or start using Haskell. Agile makes sense…
Re: Ask HN: Are we overcomplicating software development?
#318Earlier quoted context omitted.
One caveat is that if you need to fix a bug in your library in an API-compatible way, you can't reach into all the codebases that are using your library. You can deploy a new version of the microservice, though.
If you need to change your microservice's API in a non-backwards compatible way, you have the exact same problem plus significant operational complexity.
Re: Ask HN: Are we overcomplicating software development?
#319Earlier quoted context omitted.
He probably uses flock(2)
But isn't that hard to get right? At least if you using something like sqlite you get consistency guarantees. Consider your process writing to the file and dying during write() - do you recover and repair the file after you reschedule?
Re: Ask HN: Are we overcomplicating software development?
#320For a solo developer, just breaking things out into modules and massaging the formatting is likely to be a net negative - something you might do once you've accumulated months of cruft and are ready to start handing it off to others or repurposing it for a new project, but also a chore that will get in the way of thinking about the job in front of you right now, a temptation to think top-down planning will come to your rescue. Your advantage is in being able to change direction immediately, and there are a lot of ways to give that up by accidentally following a practice for a larger team.
As a team gets bigger, it's more important to be cautious because of momentum; any direction you pick for development will be hard to stop once it gets going.
At the same time, there are processes and automations that help at every scale, and at the small scale they're just more likely to be little scripts and workflow conventions, not ironclad enforcements.