3 ms·

You can't really fix things like software publicly. That'd never fly in a typical company, startups excluded of course. The only thing you can do is do it secre

by yason 15y ago

You can't really fix things like software publicly. That'd never fly in a typical company, startups excluded of course. The only thing you can do is do it secretly and there are practically two ways to accomplish that. The first way is hard to do if there's a large group of programmers working on the project but it's very suitable for older projects that is still under development but with lower staffing. If possible, do things efficiently locally (use source control, use python/jython, generate code, do automated builds, do automated testing, reuse, and only deliver what you must) but leave your advantageous practices unadvertised. Then, slowly abuse your edge to steal maintenance and refactoring time from actual to-be-done tasks and features. Eventually you can ease your own future work and you'll get more time to work on the system instead of the features which become easier to add. The second way is to employ a targeted attack against a whole malfunctional group or team at once: skunkworks projects. Do the damn thing from the scratch and do it right, then replace the old steaming pile of junk with it before anyone gets to say no, and weasel your way back to the surface by toting things were just changed a bit, and never replaced. Of course, this comes with the assumption that the evil is in the system and your colleagues aren't actively demolishing everything you build.

ido 15y ago
Do the damn thing from the scratch and do it right, then replace the old steaming pile of junk with it This reminds me of the many attempts to rewrite nethack in a higher level language, like ruby or python. They all fail miserably, leaving nothing but a smoking crater and piles of code that is never to be used. Turns out all those millions of lines of c code written over a period of 25 years actually do quite a lot.
- morsch 15y ago
  Yes. Programmers (myself included) constantly want to rewrite form scratch: But this time, we're going to do it right! Unfortunately, often, you'll draw exaggerated conclusions from past failures and over-engineer things ("All problems in computer science can be solved by another level of indirection."). You might also end up creating new design problems, e.g. a bottleneck in an area that the old design just happened to avoid. And even if you do get everything right design-wise, you'll always end up creating new bugs along the way. (Obviously, none of this is a new insight, the pros and cons of rewrite from scratch have been discussed back and forth forever.)
- gbog 15y ago
  Yes, this point of view is well known and well documented. But the opposite may have some weight too. I think I read somewhere that Google codebase had been rewritten from scratch. Maybe it was early enough, because I suppose rewriting it today would be painful. Are there any other successful rewrite from scratch stories? Maybe vim?
  - robfig 15y ago
    Google doesn't "rewrite" things in the traditional sense.. they develop new versions of old systems when the old system has reached the limit (or is just grossly inefficient). The new systems generally are not at all architecturally similar. I don't think I've ever heard of a rewrite "because the code was messy" or anything other "it can't do X and we need X".
kablamo 15y ago
I feel secretly rewriting software from scratch is rarely the right solution. Especially if management has already decided thats not the direction they want to take. Your job as an employee is to make your boss happy. If you don't have political buy in from your boss then he/she isn't going to be impressed that you have been spending all this time on this project instead of spending that time on whatever it is that is important to them. Even if its overtime. If you disagree with your boss that radically, then you should find a new boss because you won't be successful in your current position. And also because you won't ever be happy. Find a boss who you get along with. And be happy.
rick888 15y ago
I take a different approach, mostly because I've fought hard to do the right thing..and it rarely works..and I usually end up looking like the bad guy. I do what my managers want and when things start falling apart, I remind them about the warnings I gave them before-hand (sometimes with a smile) I don't worry about the business-side of things because I'm not a partner in the company and it's not my job. If these situations happen too often, or I get blamed, I leave and find another job (usually with better pay). I saved my last company from many disasters because the boss decided to let his 20 year old wife with absolutely no experience make business and marketing decisions based on what she was feeling that day. It was actually pretty interesting, because I used it as kind of a testing ground for the worst ideas ever. In many cases, the results were predictable and entertaining. In 2008, we saw that things were getting bad. Orders were slowing down and management asked me to give them some marketing ideas. I gave a bunch of ideas that were inexpensive to implement, but would take time. They didn't listen. Fast-forward to 2010. They want to start trying my ideas. When they weren't making money in 2 weeks, the ideas were considered worthless and dropped. Sometimes you just have to let children touch a hot iron to see what it's like to get burned. The smart ones will learn from this and not get burned in the future.
th0ma5 15y ago
I think some of the other replies don't quite get your do-it-in-secret concept, but I completely understand what you imply, it isn't so much that you're advocating a complete rewrite of a codebase (or at least, not just that). I think you're talking about entire build out and a conceptualization of an entire system that comes from a single narrative, and is thus, coherent. I have witnessed this in others and done this myself in various projects, and you could say it was a hack, or maybe it was making a whole bunch of decisions with various scripts or procedures, but without letting anyone know that it could be an issue until you had just went and done all of it because you were simply too tired of all the bitching and other (actually really great) competing suggestions. I think that's perfectly fine if it moves things forward, and can be a great help to a climate of dysfunction, but you can't fuck it up, so it would be like a very very last resort thing possibly.

by yason 15y ago

ido 15y ago

Do the damn thing from the scratch and do it right, then replace the old steaming pile of junk with it This reminds me of the many attempts to rewrite nethack in a higher level language, like ruby or python. They all fail miserably, leaving nothing but a smoking crater and piles of code that is never to be used. Turns out all those millions of lines of c code written over a period of 25 years actually do quite a lot.

morsch 15y ago
Yes. Programmers (myself included) constantly want to rewrite form scratch: But this time, we're going to do it right! Unfortunately, often, you'll draw exaggerated conclusions from past failures and over-engineer things ("All problems in computer science can be solved by another level of indirection."). You might also end up creating new design problems, e.g. a bottleneck in an area that the old design just happened to avoid. And even if you do get everything right design-wise, you'll always end up creating new bugs along the way. (Obviously, none of this is a new insight, the pros and cons of rewrite from scratch have been discussed back and forth forever.)
gbog 15y ago
Yes, this point of view is well known and well documented. But the opposite may have some weight too. I think I read somewhere that Google codebase had been rewritten from scratch. Maybe it was early enough, because I suppose rewriting it today would be painful. Are there any other successful rewrite from scratch stories? Maybe vim?
- robfig 15y ago
  Google doesn't "rewrite" things in the traditional sense.. they develop new versions of old systems when the old system has reached the limit (or is just grossly inefficient). The new systems generally are not at all architecturally similar. I don't think I've ever heard of a rewrite "because the code was messy" or anything other "it can't do X and we need X".

kablamo 15y ago

I feel secretly rewriting software from scratch is rarely the right solution. Especially if management has already decided thats not the direction they want to take. Your job as an employee is to make your boss happy. If you don't have political buy in from your boss then he/she isn't going to be impressed that you have been spending all this time on this project instead of spending that time on whatever it is that is important to them. Even if its overtime. If you disagree with your boss that radically, then you should find a new boss because you won't be successful in your current position. And also because you won't ever be happy. Find a boss who you get along with. And be happy.

rick888 15y ago

I take a different approach, mostly because I've fought hard to do the right thing..and it rarely works..and I usually end up looking like the bad guy. I do what my managers want and when things start falling apart, I remind them about the warnings I gave them before-hand (sometimes with a smile) I don't worry about the business-side of things because I'm not a partner in the company and it's not my job. If these situations happen too often, or I get blamed, I leave and find another job (usually with better pay). I saved my last company from many disasters because the boss decided to let his 20 year old wife with absolutely no experience make business and marketing decisions based on what she was feeling that day. It was actually pretty interesting, because I used it as kind of a testing ground for the worst ideas ever. In many cases, the results were predictable and entertaining. In 2008, we saw that things were getting bad. Orders were slowing down and management asked me to give them some marketing ideas. I gave a bunch of ideas that were inexpensive to implement, but would take time. They didn't listen. Fast-forward to 2010. They want to start trying my ideas. When they weren't making money in 2 weeks, the ideas were considered worthless and dropped. Sometimes you just have to let children touch a hot iron to see what it's like to get burned. The smart ones will learn from this and not get burned in the future.

th0ma5 15y ago

I think some of the other replies don't quite get your do-it-in-secret concept, but I completely understand what you imply, it isn't so much that you're advocating a complete rewrite of a codebase (or at least, not just that). I think you're talking about entire build out and a conceptualization of an entire system that comes from a single narrative, and is thus, coherent. I have witnessed this in others and done this myself in various projects, and you could say it was a hack, or maybe it was making a whole bunch of decisions with various scripts or procedures, but without letting anyone know that it could be an issue until you had just went and done all of it because you were simply too tired of all the bitching and other (actually really great) competing suggestions. I think that's perfectly fine if it moves things forward, and can be a great help to a climate of dysfunction, but you can't fuck it up, so it would be like a very very last resort thing possibly.