Software Over-Engineering Debate

I'm advocating not to wing it, design up front and then follow that design. When the design is found lacking, redesign with the entire system in mind. Basically, all I'm saying is do not take short cuts, they are not short cuts. Your project may finish faster, but you are harming yourself as a developer.

This is an essential part of software design today in General. If a part of your system takes time to develope, it should be an instinctive signal to look an alternative. When all of your time is spent on creating value for the customer instead of tweaking technology, you are on the right path. If you find yourself tweaking, you need to stop and look for alternative approach. This does not mean hoarding more tools as I have seen many do, because tools have a maintenance cost.

Biggest thing for me is to stop prematurely over-engineering things. Need something done? Just get it done, however possible. If, in future, you need to do it many more times, you can gradually optimize the process as you go. As opposed to letting the perfect kill the good in the first place.

I have the same experience. I could go ahead and start implementing. But that means committing to a particular design. The first design that comes to your mind is typically not the best at all, why would it be. Therefore I feel hesitant to start coding it right away. Give the design-ideas some time to boil a bit in my head while perhaps focusing on something else. The better designs then typically pop up and that saves a lot of work in the future. And eliminates a lot of unnecessary technical de

Yes, this can be a problem. Learning the difference between ideal and good enough to get the job done is important. Also, avoid the planning for every eventuality, work with what is known.A common issue is someone saying, well I want it to do "X" in the future. Well great, then in the future you can refactor it to do "X", in the meantime I have to make it work and get it out the door. I will try to not do anything that would make "X" harder, but I won't

Premature optimization may hit them hard. Overengineering is imo usually the bigger technical debt and a huge upfront cost as well. Well-thought out plans tend to become a sunken cost fallacy. Making room for changes is hard enough in XP like ways of working. When you have to tell your manager that half a year of careful plans and engineering can be thrown away, because of the new requirements, which emerge from late entry to market, you look like a clown. Plans and complexity usually introduce

You neglect something I think is very important: You do not normally know up front what code will live and not.If you carefully (over-)engineer everything you will perhaps not get time to write all those short-lived failures that preceded that long-lasting success.Of course I wish that piece of code that I hacked 3 years ago and never got around to refactor was better done the first time! But that kind of thinking ignores the fact that if my mentality had been "perfect up front"

Engineers should avoid pursuing the perfect, most-generic, elegant solution. Spending too much time to decide the best tools, the right design pattern, etc. Coding is a lightweight process (compared to other forms of engineering). So it is easy to go back and rebuild and upgrade, which will be required in any case.But of course watch if the need to redesign/rebuild becomes a pattern. Then invest more time up ahead. But most times, a decent engineer is able to get to a fairly accurate and

This is true sometimes, but a few things happen as you keep writing software:1. By writing the needed code the "debt incurring" way, you learn how to do it the "right" way. So you may start with inexperience, but you gain the experience and are now better able to fix the issues you introduced.2. Similar to this, even if you have all of the necessary experience and skill, you still may not be fully able to picture how the feature will need to evolve in the future

Pretty much this. It's especially true in startups where new features and edge cases pile up really fast. Solve a new edge case manually in the beginning (like adding a simple field instead of a smart calculation, like you mentioned) and work from there. It might turn out, in a few months, that that new feature nobody uses anyway so it's dropped. This is easier if you obey: 6) Think at product level