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!
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.