How to program an application with unknown future modifications and features?

Question

Background

I'm not new to programming, however I am when it comes to handling clients and their needs. Here's my history with my current client: I inherited a PHP application with it being 2/3 completed, continued to make it 100% completed until the client wanted (major) features that caused the application and database to need to be rewritten. I spent two weeks drafting how the new application would work with the new changes along with other needed features and after approval I started the building the application, again. I'm now being asked to add new features that were not discussed before the new build- and again, they are pretty major. Also, the whole application is live with over 300 users- making it even harder.

Question

Ignore the fact the client is asking for features not discussed originally. How do I make the applications I build feature proof? In a prefect world, the client would know exactly what features the application should have, which would make it a lot easier to do my job. But this is not the case and these major features I'm talking about are those that should have been included while drafting the application, not when the application is live- though this question is general for any future modification or feature to an application.

I don't like telling my client the feature or change he is requesting is so major that I have to rewrite the whole application (again). However, while writing this it occurred to me that it may not be my fault that the feature can't be added without starting over. But this seems to almost be any new feature he wants, as some things have been hard coded for the application and changing them now for a new feature just wont work.

Any personal experience with this situation would be great- I hope I'm not the only one dealing with this, as it can be very frustrating. Thanks!

Answer 1

Hooks.

The best way to make something extensible is to make it have many clearly-documented insertion points for additional code. The less the original program has to be modified to accomodate a new feature, the better. This idea is behind "extensions", "add-ons", "modules", whatever - make it so that someone can improve your program without having to touch its source code at all.

Answer 2

You can't ever make something completely future-proof. Specs are drawn out for a reason...so that they can be adhered to. Although I would say if the client wants to pay money for each major release, that's their prerogative.

Answer 3

Since PHP supports OOP and my schooling has been OOP from the start, I would suggest that you learn Object Oriented design patterns like the back of your hand. Also, think "code to an interface" a lot. The way the architecture is set up in the first place has a lot to do with the maintainability of the code in question. You may be able to leave the application alone and redesign it from the ground up then swap the system in its entirety. This makes dealing with 300 users easier than updating small parts at a time.

Design patterns: http://en.wikipedia.org/wiki/Design_pattern

Answer 4

Depending of the needs, a "plug-in" application model could be used.

Answer 5

Try to plan ahead for features that might be added later on, and use a design that can encompass those features without a complete re-write. There's obviously a trade-off between initial complexity and the ability to easily add stuff later, though.

Making things modular and loosely coupled also helps. If you have a component with a fairly well defined API it's easy to replace its implementation entirely without touching much or any of the code that's using it.

Answer 6

Anticicoding major new features is hardly possible. There are however a few spots where planned flexibility is always a good idea. Foremost it makes sense to keep the database interface abstract and table fields extensible. It's often easy with active record or table data gateway or similar schemes, sometimes a simple $fieldnames[$table]=[a,b,c] might suffice.

Second of course, try to build the core application upon hooks or plugins. Though, that again only helps for extensions, not major changes.

If you have existing users and rework a live system, it might help to implement database views (even versioned?), keep the old application and build the new version on an extended storage scheme. But really, that's difficult to asses on a generic description.

Answer 7

Two concepts come to my mind: "you ain't gonna need it" and "keep it simple, stupid". I.e., coding for future features, in my experience, is a trap for creating terrible code, and then the future comes differently anyway. But maybe that's just me.

Answer 8

Be assured that this is an old problem. Most programmers have had to deal with some manager or decision-maker who has a new vision for the app every day. They don't seem to understand that it takes a lot more work to automate something than it takes to describe it at a high level. They also don't seem to understand that it takes a toll on the morale of their workers to be told to tear down something you just worked hard on.

It's a hard problem to try to anticipate all the ways one could be asked to redesign software. Some people have suggested hooks so that you can add new functionality at any given step of the workflow, without having to tear apart the application. But which hooks should you add? And what if the workflow itself needs to change?

Many software developers use methods like Agile Software Development or Extreme Programming or other iterative methodologies.

One of the common ideas of iterative development is that you shouldn't try to anticipate all future change. Some of the changes you anticipated will happen of course, but it's just as likely that many of them will not, so the work you put in to anticipate possible changes is wasted effort.

So you should just write the software that is needed today. You will have to rewrite some of it as things change, but that's normal and unavoidable. And it's likely that most of it will not change, so the simpler design is better. The assumption is that by focusing just on the current requirements, you reduce the overall work enough so that it's a net win.

Of course they also say that you should respond gracefully to change when it does happen, and mitigate lost time by communicating with the client (or manager) frequently. Mock-ups and prototypes are useful tools in this case. Also don't be afraid to tell your manager truthfully how long it is going to take you to redesign the software to meet his description. You can help by proposing some compromises. For example, often a single feature that he asked for is the reason you need to rearchitect, and otherwise the changes would be a lot more minor. So talk openly about this, and have a dialogue to see if there's another way to solve the same need without so much work. It should be in his interest too, if he can get that need met more quickly and less expensively.

Eventually, though, you might face a manager who is completely senseless. No amount of negotiation or improving your methodologies can help in this case. Don't work for someone who is persistently disrespectful of you and your time and the product of your work. And don't let them walk all over you or guilt-trip you into working long hours.

Also read this humor piece, which probably mirrors your situation: If Architects Had to Work Like Programmers.