0

I just joined a new company which is a new start up, STILL applying for funds etc. The product is very promising and likely to be a success once fully released to the public (we're currently in a closed beta). It has a very nice user interface and an easy experience, so design wise it's top notch.

However, the application itself is written quite poorly. I'm a Senior Web Developer in this company and I was a little shocked with the lack of structure of the code. The manager (Main Senior? Can't think of an appropriate name) is very logical and always has the right solutions in mind and can also code them out nicely, but they are not very efficient performance wise and don't follow any particular concept (eg. DRY).

We use a kind of a MVC model, but it's not very efficient and does not save us from the headaches it should fix. Code repetition is a major problem and so is the amount of jQuery, Ajax calls, unnecessary timeouts etc. The database abstraction layer seems very inefficient too and it doesn't include any sort of ORM. So to sum this up, the code is a mess, but the product works (can't judge the security yet).

I would be able to take the whole project and code it from scratch with some rules in mind. I would make it easy to extend while preserving the same functionality, though it would take a while since a lot was done.

I would incorporate things that would make development for the future team very seamless, such as:

  • Use of version control (Git). We do this, but not as much as we should.
  • Use an already existent MVC framework that is updated and maintained by a community on regular basis (eg. Rails, Laravel, Django etc.).
  • Enforce DRY.
  • Do test driven development (optional, but useful).
  • Use a Javascript framework and avoid the use of jQuery to manipulate the DOM (eg. ReactJS, AngularJS etc.).

Anyway, I don't know how to approach the manager about this. It would take additional resources to get this started and done. Also time. But I know that as soon as we go online and get huge amounts of visits, we'll end up exploding and patching things in that mess, until we end up rewriting the whole thing or the product failing altogether.

What should I do?

Improve this question
  • 6
    So the current product looks good and does what it was designed to do? I am struggling to see why the company would want to throw it away and pay someone again for creating it. Why should they do this when they could refactor the code on-the-fly as required? Why does this not apply: joelonsoftware.com/articles/fog0000000069.html – Marv Mills Oct 12 '15 at 13:57
  • @MarvMills It's prone to failure. The mess is huge and I have already done some major refactoring myself. Still, to patch the whole thing up and make it an easy extensible product would take as much as writing it from scratch. Plus no one provides updates for our own framework, which will cost even more resources in the future in order to mantain it. – aborted Oct 12 '15 at 13:59
  • 1
    I've seen many instances of companies that went almost or all the way through their demise by rewrites. If it "works", and there is no pressing reason to rewrite it I doubt the owners/managers will agree with stopping everything and go through a rewrite without sufficient evidence that it is for their benefit to do so. – user1220 Oct 12 '15 at 14:03
  • 3
    This question appears to be very specific to software evelopment and not very applicable for other professions. This makes it more of a question for programmers.stackexchange.com than for workplace.SE – Philipp Oct 12 '15 at 14:14
  • 1
    I tried to migrate this to Programmers, on the recommendation that it be migrated there but it appears you are blocked from asking questions there. A moderator there also suggested it would be closed as a duplicate of this however - programmers.stackexchange.com/questions/43948/… – enderland Oct 12 '15 at 14:37
6

I kind of doubt you're going to convince them a rewrite is in order when they're at such a late stage. The success of a new company depends on getting a product out the door, and rewrites at this stage would seem like unnecessary and costly delay to higher ups. And not unjustly so, as rewriting would mean investing significantly more time and money without releasing any product to make that back. That kind of thing has driven many a start up out of business.

What I would do first is start talking about and pushing for better practices like the ones you mentioned.

Secondly, I would keep an eye out for obvious and easy areas of the code that you could improve, and convince your managers that these are good places to work on. You'll probably not meet much resistance there.

Keep talking about how you perceive the state of the code, and areas you think would be the best to fix. You'll end up with incremental improvements, but with enough of those you can significantly improve your code quality.

Eventually, some time down the road, once the product has proven itself, and the code debt has surely added up, you'll probably get your opportunity to convince people to completely rewrite.

Improve this answer
  • 1
    +1 as I was writing more or less this... doing some load testing/analysis of the beta might help point out areas of the code that could be improved. Also, talking about and pushing for better practices needs to be done with an eye for what concrete benefits they bring to the project, rather than just them being the tools/methodologies you want to be using. – Hazel Oct 12 '15 at 14:17
3

Starting a large software development project from scratch is rarely a good idea.

While you do the rewrite, you will be unable to add any new features to the running application and only be able to do urgent-priority bugfixes. The rewrite will completely paralyze you and make you unable to act on changing business requirements.

Instead of that I would recommend you to go for an iterative approach. Keep what you have right now, and improve on it one subsystem at a time, preferably while you work on that system anyway to fulfill a business requirement.

Also keep another thing in mind: other people's code always looks worse at first glance than it is. Every programmer has a different attitude and mindset. It takes a while to get into that mindset. And while none of us are perfect or always work as well as we could given infinite time and resources, our solutions usually at least make sense for ourself. When you take the time to familarize yourself with the patterns used by your predecessors and try to trace the thought-processes which lead to their design decisions, their code usually becomes a lot more logical than the first impression.

Improve this answer
  • 2
    I disagree, starting from scratch can be an excellent idea - 6 months spent "doing it right" now can save several decades of technical debt. I've worked on software at several companies where we (both support and development teams) were struggling along with an old, terrible code base. Equally developing from scratch is not automatically the answer. – Jon Story Oct 12 '15 at 14:48
  • It's a bad idea if 6 months spent "doing it right" mean you never get to the several decades of technical debt because you are out of business. – gnasher729 Apr 20 '16 at 15:52

Not the answer you're looking for? Browse other questions tagged .