4 ms·
I think its a great reminder to code with whatever you feel comfortable. For example, my last project I did in Centos/Apache/PHP5/Code Igniter 3.1 with some WAS
by joering2 3y ago
I think its a great reminder to code with whatever you feel comfortable. For example, my last project I did in Centos/Apache/PHP5/Code Igniter 3.1 with some WASP for protection I did for 12 years and sold few months ago. It checks out against Qualys Server test and ImmuniWeb very well. I sold it for close to $10MM with annual revenues of $1.6MM. The last question the new owner asked me was "what did you program it with?". They mostly want bunch of boring excel spreadsheets seeing where I am, how the sales are sustained, and how do I believe it can grow. On the final day, their IT guy showed up. He looked in silence through 45 minutes of my code's presentation, which is very much mix of OO and not OO, and his only words were "I don't like frameworks if that was me I would start the whole thing from scratch".
So you never know what or whom you gonna get, but the bottom line is if you have sales and revenues and keep tabs on spending, they will come, and they will not care less about your fancy framework or newest code implementations.
TLDR: code in whatever you feel comfortable but always consider security as top priority (not speed) because in production your code's/setup security mistakes can cost you serious legal troubles.
- sockgrant 3y agoGotta love engineers. 45 minutes of reading 12 years of someone’s work and the first thing they say is “yeah I’d rewrite it”. Every. Dang. Engineer. It’s crazy. I try to work in a codebase for 3-6 months before coming to any wild conclusions. Usually you find that there’s some warts but it does the job and there’s complexity that was solved that you hadn’t originally noticed, and it’s not worth rewriting it just needs some love in some areas. People hate reading other peoples code.
- zdragnar 3y agoA clean rewrite is almost always going to produce better code than what already exists in a project that has grown organically. The current project has had numerous iterations on requirements over the years, changes in project leadership, paradigm fads come and go, and all that time accumulating cruft and layers. Looking at it at a single moment in time, you have a fixed set of current requirements where all the discovery has already been done, plus whatever your current knowledge of future requirements is, possibly none of which may have existed when the original code was written. That doesn't mean that everyone is going to sit around on their thumbs patiently waiting for you to rewrite it to be perfect. The more lines of code there are, the more time it will take, and the more hidden features that nobody really remembers exist but are still crucial will crop up. Few situations are actually best served by a full rewrite, but almost every project would be better off if the world could stand still long enough for it to happen.
- athrun 3y agoIdeally, you want people deeply familiar with the original codebase doing the rewrite. What usually happens instead is that the rewrite happens because the original code has been handed off to a new set of people. They're not deeply familiar with the code. It's confusing to them. It's not obvious why things have been done in a specific way. And so they decide rewriting it from scratch is the better option. Unfortunately, they're not in the best position to come up with a solution that incorporates the right lessons from the original design.
- minusf 3y agoa rewrite from scratch is a pipe dream for almost everything bigger than "hello world". just ask WordPerfect. any kind of home grown business app will have corner cases and requirements spaghetti that would take much more time to figure out than to write actual code. and if the person asking you to do a rewrite just shrugs when you ask "where is the test suite?" walk away asap.