2

I understand there is plenty of information on the internet about planning and implementing said solid plan in building a large software application, but I was hoping to get something a little more specific to aid my approach for this specific instance.

Some Background:

We're a web hosting company that has a team of 3 developers. My colleague and lead developer has been with the company a few years, and up until myself, and another developer were hired, he was the sole one looking after all the company's projects.

All three of us have very little experience in leading a team, or even working with other developers in a meaningful sense. We've all come from small business backgrounds where input has simply gone in our ears, and code has come out.

There's some benefits to our position as well; our team is fairly autonomous. Apart from a few directives given by management, we have total control and freedom in managing our projects, deadlines and the tools used to implement our solutions. It's a pretty great gig, but we're all around the same age (early-mid twenties) and so there's not so much team-lead experience there.

The Application:

Our current billing system is the oft maligned WHMCS - which is a plight of many other hosting companies I'm sure. As a result, we've been tasked with designing a replacement that has all of the features we need specifically for our operations.

At the start of the year, my lead developer began working on it. This was the traditional case of 'begin prototyping and see what happens'. While his code was great, and the foundation solid, there was zilch going on in terms of scoping (the designer hadn't even looked at it yet), and now the code base is starting to creak under it's own weight, and it's barely a third done.

Me:

I've come along from a small web design business where I was considered the 'go-to' guy, so I took it upon myself in many instances to attempt planning a project that more than once has saved the profit margin from dipping into the red. This has helped a little in convincing the lead developer to adopt a more careful, structured approach that allows us to work as a team, and have this quite critical piece of software not be a steaming mess of bug fixes and hacky patch-ups.

I'm a journeyman developer, so I'm not well versed in best practices, I don't know three or five or ten programming languages, but I can code. And I'm a great communicator (in real life, not when writing questions like this ~_~), so I hope what I learn here will be able to directly translate into something that benefits our small team.

The actual question:

For a big old 'TLDR;' here: What are the preferred methods of planning a large codebase? We're our own masters in this, so we have no guidance. Muchas gracias in advance!

1 Answer 1

2

The issue you are facing IMHO is a growing amount of technical debt. While usually attributed to poor design, I attribute to overall poor software engineering practices. The problem is, once you've accumulated some, you'll have to pour a bunch of resources in to get out of it before you start seeing major improvements. But in the end, I promise the work will pay off.

I'd say make sure to build it iteratively. IMHO you want to get to a usable and testable code base ASAP, so figure out the minimum set of functionality you'll need to have a product. Not even a competitive product, just a thing that works. This should help keep you focused and keep you from adding too many YAGNI features. If you get into the swing of quick iterations, you can also use them as a vehicle for slowly increasing your software control capabilities.

You didn't mention it in your post, but you had better be using some sort of version control. Make sure you have an issue tracker (its all in my head is a terrible way to track issues). Make sure you fix bugs before moving on to adding features. Implement a continuous integration and test server. Not all of these are necessary for all projects, and they come with a pretty steep cost for setup and training, but they are worth it in the end.

When possible you want to split your code into reusable modules. Got a bit of code that handles authentication? Put it in its own module. Ect. It is very possible to do this too much, but done well it can increase your code re-usability. In some build systems this can also be a mechanism for caching the build, so that you only remake or retest elements of the code that have changed.

Finally, I suggest adopting a company wide coding standard and enforce it through code reviews. One of the highlights of your post to me was "lead developer began working on it". It sounds like only one guy is touching the code...this scares the crap out of me. You need to have shared ownership of the code, else when the lead gets tired of working on this code base and moves to a different company you'll be up the creek without a paddle. Coding standards help make all the code in the company "feel" the same, which can help readibility, but I do enjoy code reviews. Done correctly, they can really be used as a learning tool and help everyone understand all of the code to some degree (done poorly they can serve to only make all your engineers hate each other.)

2
  • Stellar answer, exactly what I was looking for :) While the technical debt is an issue, it's not so irreversible at the moment, which is why I have endeavoured to nip it in the bud before it got out of control. I had a chat to the lead developer, and was was very open to these ideas, which was great. For your peace of mind, I can assure you that there are good version control practices in place already here (which is great, at least for this application), but regardless I really appreciate the time you took to give me exactly what I needed!
    – Jerricco
    Nov 21, 2014 at 3:08
  • I'll keep the question open however, it's always good to get other's perspectives on these things :)
    – Jerricco
    Nov 21, 2014 at 3:13

Not the answer you're looking for? Browse other questions tagged or ask your own question.