• 0 Posts
  • 29 Comments
Joined 1 year ago
cake
Cake day: June 12th, 2023

help-circle






  • It’s actually the company’s problem. They usually opt to add more debt though, rather that wade through the old stuff.

    In the end, all software sucks and should be replaced as soon as possible. Code quality is a lie we tell ourselves so that we can sometimes be proud of our work. It’s usually the code we are most proud of that is the worst. Design patterns everywhere making the vode overly convoluted and “future proof”. The only future proofing that happens is that no-one will understand it, so they won’t change it. Trying to design for the future usually makes it harder in the future.






  • Yes you should. I think most comments here are about products that have millions of users where it’s actually worthwhile spending all that extra time and money to perfect things.

    For most development, it isn’t worthwhile and the best approach is to wing it, then return later to iterate, if need be.

    The same goes for most craftsmanship, carpentry in particular. A great carpenter knows that no-one will see the details inside the walls or what’s up on the attic. Only spend the extra time where it actually matters.

    It triggers me immensely when people say “I could have made a better job than that” about construction work. Sure maybe with twice the budget and thrice the time.






  • That leads to focusing on the nitty gritty details first, building a library of thing you think you might need and you forget to think about the whole solution.

    If you come up with another solution half way through, you will probably throw away half of the code you already built.

    I see TDD as going depth first whereas I prefer to go breadth first. Try out a solution and skip the details (by mocking or assuming things). Once you have settled on the right solution you can fill in the details.