4 ms·

I agree with you. Only the very best developers that I have worked with advocate for principles like: no rewrites, refactor only; less is more; minimal viable p

I agree with you. Only the very best developers that I have worked with advocate for principles like: no rewrites, refactor only; less is more; minimal viable product with customer feedback loops; reducing complexity; a/b testing, etc. My best work has been alongside product managers that push back on new features. I have never seen a rewrite that was functionally better than the original. I honestly don't have any experience working with a team that produces a top-shelf title, like a popular web browser, spreadsheet, or calendar application. I've only been involved working on internal facing "intranet" business applications, because that's where the majority of the jobs are. That being said, I wonder if what you're describing is worse for internal applications, simply because teams don't really "listen" to their users (employees)? I don't think I've ever seen a nice intranet or internal payroll application, for example. My current company, which is a very big F500 company, has one of the worst payroll and HR apps considering its size. Intranet applications tend to accumulate every departments special hidden feature without anyone keeping it in check. Looking at Apple I feel that most of their customer facing applications and operating systems are getting worse not better. They are getting too "clever" with their user interfaces, relying on tricky unintuitive user interface gestures and hidden button clicking. I wonder if the symptoms you describe manifest themselves at Apple as UI "cleverness."

christophilus 10y ago
I've over-engineered plenty of software in my time. Most of the time, it was because of boredom with yet another crud app. An anecdote about rewriting: I've also been involved in 4 successful rewrites. The decision to scrap/start over is rarely a good one. In my case, my team had inherited a bizarre suite of apps that combined VB6/C++. It was full of memory leaks, and had never been successfully deployed in the 3-4 years of its existence. We rewrote the entire suite in a year using .NET (1.x at the time). We (developers) went onsite to a bunch of our clients and watched them work, figured out what the system really needed to do, and made it do exactly that. The result was the first successful deployment the company had had in 4 years. It also sold itself in sales meetings, because it had been designed by watching users, rather than by guesswork. So rewrites can be done. The question is: how bad is the underlying system? And how much easier is the problem to solve in technology X vs Y? In our case, the underlying system was atrocious, undocumented, untested, written by a COBOL programmer who did not understand VB or C++ or OOP. And the .NET WinForms stack was vastly more productive than the C++ (and even the VB6) stacks we were replacing. The decision to rewrite was pretty easy.
- jtrtoo 10y ago
  This seems successful because It's less a rewrite and more of a build a different solution that actually fits the need. Which is a good reason to dump something that isn't appropriate any longer. Or, worse, never was appropriate. :-)

christophilus 10y ago

I've over-engineered plenty of software in my time. Most of the time, it was because of boredom with yet another crud app. An anecdote about rewriting: I've also been involved in 4 successful rewrites. The decision to scrap/start over is rarely a good one. In my case, my team had inherited a bizarre suite of apps that combined VB6/C++. It was full of memory leaks, and had never been successfully deployed in the 3-4 years of its existence. We rewrote the entire suite in a year using .NET (1.x at the time). We (developers) went onsite to a bunch of our clients and watched them work, figured out what the system really needed to do, and made it do exactly that. The result was the first successful deployment the company had had in 4 years. It also sold itself in sales meetings, because it had been designed by watching users, rather than by guesswork. So rewrites can be done. The question is: how bad is the underlying system? And how much easier is the problem to solve in technology X vs Y? In our case, the underlying system was atrocious, undocumented, untested, written by a COBOL programmer who did not understand VB or C++ or OOP. And the .NET WinForms stack was vastly more productive than the C++ (and even the VB6) stacks we were replacing. The decision to rewrite was pretty easy.

jtrtoo 10y ago
This seems successful because It's less a rewrite and more of a build a different solution that actually fits the need. Which is a good reason to dump something that isn't appropriate any longer. Or, worse, never was appropriate. :-)