How to write flexible and reusable code in a business where we make custom apps (fast)?

Question

It looks like a vicious circle... We always have a near impossible deadline. So, we code as fast as possible. The client get its app in time, but if he want to change something afterward, it'll cost him a lot more than if we took time to write super flexible code. Who can blame our bosses, they are still making money, right?

Sure it would be nice to make general modules that we could reuse, we'll save time in the next couple of projects, but it seems that we don't have that time, and our bosses won't give us this time either... they don't want to bust their budget. Also, it would be great to work in maintainable code, but we don't have the time to "refactor" anything anyway.

So, anyway, my question is : How can you work in such environment and still make maintainable and reusable code without busting budgets? Is it even possible?

Answer 1

Learn Refactoring, and Test-Driven Development. With adequate unit test coverage, you'll have the confidence necessary to refactor your code into reusable modules - knowing that you haven't broken anything.

Answer 2

I feel for you. I used to work in that kind of environment. However, you are going to learn a lot, and part of what you are going to learn is doing what works. In your environment that means keeping it simple, which pretty much leaves out complex patterns.

If I had one piece of advice, it would be to start making Unit Tests for what you code, if you are not doing so already. Unit tests give you a regression test suite that you can use to prove that you didn't break something when you changed that last bit of code.

In your environment, my guess is that, unlike more formalized environments, you have some leeway to decide how your work gets done. Use that flexibility to find ways to get better and more efficient, and incorporate those practices into your work.

Answer 3

Not having time to refactor leads me to believe that you are working in a "scary" (read-untested) code base? Refactoring should be done inline with your development. Not just after the fact.

I tend to work in your environment where I have no time to do things as right as I would like them too be. For this reason I develop against interfaces entirely which allows me to build a class for project A. I build keeping in mind how it should work for this client but also how it could work for the upcoming (unknown) projects. As I move from one project to the next I always start the new work by dragging over my base library. When I estimate my tasks for the next project I estimate just as I would if I had not drug over my existing code. This then gives me time to go in and upgrade that code so that it is better. This generally means that my boss and my clients are benefiting directly. The boss gets better code with each iteration and the client gets code that is already in production (tested and working) with some upgrades/tweaks to make things better.

A good example of this is my caching layer which has grown with me over the years. It initially started as a wrapper for the standard .NET caching system. I then added another layer between my client code and my cache wrapper. This allowed me to swap out the actual implementation of the cache layer when I needed too at which time I tried using MemCached. I am now in the position to attempt to use Velocity. Each time my widget gets better and better...without losing the experience learned or functionality gained by development over time.

I think that part of the budget/estimation/time should always be spent building a framework that not only works for the client but stream lines the workflow of the dev team. Think about it. A framework that is easily extendable is good for any one that comes in contact with it down the road. Whether it is your company or the next developer for the client.

Answer 4

If your always reinventing the wheel on each project your working very inefficiently. Try and talk some sense into your boss to let you create some reusable libraries. Don't wast time recoding something you all ready have somewhere else. I would suggest setting up some reusable libraries on your own to use in these projects. And if they won't give you the time to work on it on the clock, you might want to work on it off the clock. That will at least give you a basis for when you start a new project to have the functions and classes you use often, right at your fingertips.

Once you've proven that keeping libraries for common tasks is actually making things better, management might be willing to let you spend some of your on the clock time to develop the idea further. The more prebuilt tools you have, the quicker it can be to put something together.

Answer 5

Another idea is to take some of the work home with you so that you can create some primary coding templates in your "spare" time. The benefit of this is that you get your work done faster which may leave you some time at work to do more of the templates.
I dislike the option, but it has the capability of short-circuiting the rat race.