Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Problem: It seems with almost every development effort I'm involved in, no matter how much time is spent planning prior to starting development, there is always a large amount of changes required either midway or towards the end of the project. These are sometimes big changes which require alot of re-development.

I don't work for clients who pay money, this is an in-house development team on in-house development websites. So, it's not like I can charge for it or anything. And at the end of the day, we have to try to hit deadlines.

Questions: What are some of the best ways you guys have found to minimize and prevent spec changes from cropping up midway or after development?

share|improve this question
9  
establish a Feature Freeze milestone in development and arrange / negotiate things in such a way that all feature requests submitted after that milestone go to next release not to current one. Key point here is of course to plan for more than one release ahead and share this understanding with clients –  gnat Jan 26 '12 at 9:27
4  
@gnat You are assuming that the OP works at an organization where putting in place a Feature Freeze milestone would be acceptable to the stakeholders. Based on personal experience working on in-house development teams, if I were to propose such a thing the stakeholders would stare at me and say something to the effect of "Who the hell do you think you are telling me when I can and cannot change my feature requests on a whim? What do you think I am paying you for? Know your place." –  maple_shaft Jan 26 '12 at 12:48
27  
Have you tried saving the spec in a read-only file? –  orlp Jan 26 '12 at 14:42
14  
Of course you charge them: every change to the spec delays the release, so your response to a change request should be an estimate of the new release date if the change is added to the spec. Whoever asks for the change is responsible for the delay, and needs to explain it in exactly the same way as one would explain expenditures. –  Simon Richter Jan 26 '12 at 17:57
7  
Isn't this why Agile exists? You can't freeze the spec so make your process handle a changing spec. –  Craig Jan 26 '12 at 20:43

16 Answers 16

up vote 85 down vote accepted

There's a famous military saying, attributed to Helmut von Moltke: "No battle plan survives contact with the enemy". In the same vein, I do not think it's possible to make a spec that will not have to be changed - not unless you can predict the future and read minds of the stakeholders (even then they may not have yet made their minds, even if they claim they did). I would suggest instead approach it in a number of ways:

  1. Make a clear distinction what can be changed and what can not. Communicate it clearly to the stakeholders, make them explicitly sign off on unchangeable things as soon as possible.
  2. Prepare for the change in advance. Use code methodologies that allow to change the changeable parts easier, invest in configurability, encapsulation and clear protocols that would allow parts to be changed and replaced independently.
  3. Talk to the stakeholders frequently, solicit feedback and approval. This would both keep you in sync and avoid them claiming "oh, that's not what we wanted" when it's too late. As noted in other answers, agile methodologies and frequent mini-releases would help you with that.
  4. Put into the schedule the time to accomodate the inevitable changes. Don't be afraid to say "we will need more time" early if you think you would - if the schedule you're given is unrealistic it's better to know it (and have you on the record saying that) at the start than at the end.
  5. If the changes are too extensive and threaten the deadline - push back and say something like "this change is possible, but will push the deadline by X time, make your choice".
  6. Make a formal process of requesting changes, prioritizing changes and assigning changes to versions or releases. If you could tell people "I can not do it in this release, but will be happy to put it on schedule for the next one", it's much better than saying them "you're too late, your change can't go in, goodbye" and would make them your friend - they'd be happy for you to release in time so you could be free sooner to get to the next release which will have their change - and not your enemy.
share|improve this answer
8  
+1 for quoting Moltke :) –  quant_dev Jan 26 '12 at 9:58
3  
You can also 'freeze' them in phases and push changes into the 'next version'. –  Grant Thomas Jan 26 '12 at 10:43
3  
Formalising the change process and being clear on scope is great advice - if you are doing fixed scope/price contract work. In other settings, this approach grinds since it gives schedule and price precedence over scope and quality. Maybe that is what you need in a given situation. But then again, maybe it is not... –  tardate Jan 26 '12 at 15:15
3  
+1 for number 6. I had an excellent experience with the PM implementing that requirement alone. –  Joshua Drake Jan 26 '12 at 15:31
3  
Short cycles are key. People are much less upset about something getting pushed into the next two-week sprint than when the "next release" is six months away. –  Adam Jaskiewicz Jan 26 '12 at 18:29

Deliver something (I hesitate to use the word anything) early and deliver often. That is - use some sort of iterative development methodology.

This is the basis of Agile development, but can be used with (almost) any methodology.

By breaking the project down into a series of mini projects you get more control as you can put something in front of the client early, you're not locked into a long development schedule that becomes out of date when the client changes their mind (as they will).

When they see the system evolve, some requirements will change, some will become redundant and others will increase in priority. However, by having a short project life-cycle you will be able to cope with these changes.

share|improve this answer

The theory that it is possible to completely spec out a software project of any significant size is a complete fantasy. This theory has been found not to work in organizations from large to small for pretty much the entire history of software development.

You MUST find some way to accommodate changes as you go! They ARE going to happen, because most of the stakeholders, even if they say 'yea, that's what I want' actually have no idea what they want until it's in front of them. That's why we have so many folks adopting iterative methods.

Whether you iterate the product or whatever, you MUST find some way to accommodate these changes, because trying to find ways to not have changes is just short of asking gravity to turn itself off for a few minutes so you can go flying.

share|improve this answer
2  
NASA does it with some of their software, or at least good enough to send shuttles into space. The thing is that they actually follow the waterfall model. The spec is actually frozen. At least this is my understanding from outside the organization. –  Joshua Drake Jan 26 '12 at 15:34
5  
I've worked on several projects where we were able to completely spec out fairly significant systems (telephone switch adjuncts). The key in all these cases is that we were targeting hardware that had already been developed, and were developing to published (ITU) specs, so neither could change. So your argument doesn't hold for all projects -- just 99% of them! ;) –  TMN Jan 26 '12 at 16:06
1  
@Dunk: I know a big part of our success was our adherence to a methodology developed at Bell Labs. It was real engineering, with complete traceability from requirements to specs to designs to test plans to code to test results to deliverables. When a test failed, you could see exactly which requirement(s) weren't being met, and you knew exactly where to look for the failing code (or failed design). It takes a lot of discipline and oversight to make waterfall work, but you're right, it can work well. –  TMN Jan 26 '12 at 20:31
1  
@TMN I wonder then which is the key to success. The use of the waterfall model, or your disciplined approach? I am thinking the later is the more important of the two. –  Ross Goddard Jan 26 '12 at 21:06

Don't try to prevent change, embrace it. The more you plan ahead, the more likely your plan will change. So, plan less, not more. Adopt an agile development methodology where you deliver small chunks of working code frequently, giving the customer the chance to change the specifications every couple of weeks.

share|improve this answer
6  
@Dunk You are correct in that it is cheaper to change a diagram then code, but how do you discover that change needs to take place? Often times this will only occur after you have given the user something to use and he realizes either he communicated the wrong idea, this is not what he wanted, or there are these other things he wanted as well. The trick is to figure out how to discover these changes as soon as possible. –  Ross Goddard Jan 26 '12 at 21:21

You're asking the wrong question. Spec changes will always happen in software development projects of any size.

Often it's because business requirements change but I've also seen it happen because customers (internal or external) can find it hard to visualise what is possible without seeing something to iterate from, so they have a vision which slowly changes as they engage with the developing solution.

The question you should be asking is not "how can I lock the spec down", it's "how can I structure my code and processes to respond to a changing environment without throwing away everything I've already written?"

This then leads you into the buzzword bingo arena: agile methodologies, iterative development and technical solutions such as component based / modular coding, continuous integration... the list goes on.

I'm not saying these are a silver bullet to all your problems but they all came about because of a desire to manage the very situation you're describing so at the very least they're worth some investigation.

Sorry if that's not offering concrete solutions but I tend to think a mindset shift into accepting and managing change will pay bigger dividends than trying to avoid it.

share|improve this answer

A change is only a surprise ... if it's a surprise!

I'd suggest thinking about:

  • where on earth do these changes come from anyway?
  • why aren't you aware of them earlier?
  • why aren't you contributing to these changes (and potentially making even more of them)?

Change is nature of what we do. Since when did you code an algorithm exactly as envisioned on day 1?

But if you want to avoid perpetually being the frustrated developer "surprised" by changes, I think you need to find you way closer to the action of where decisions are made. After all, I'm sure you have a bucket load of ideas of how you could make the product better. Get a seat at the table, or forever accept that you will just have to deal with those "surprise changes".

share|improve this answer

This is why it is nearly impossible to plan too far in advance, but not an excuse to not plan at all. Don't fall too deep in love with your plans and you won't have to worry about them breaking your heart.

Inside your company there is a cost to using the IT resources whether anyone admits it, tracks it, or has to budget for it or not. The reality is, your team can only create so much code in a certain amount of time. All departments and projects are sharing in this budget.

You can't prevent anyone from wanting to change the requirements, but they cannot escape the consequences. Changes can significantly increase development times. That is a fact they have to deal with or decide not to make the change. Does a request from one department affect another? You may have to completely move their project behind another departments because the change request will encroach on another group's time schedule.

share|improve this answer

Well thats a though call, clients always want more but here are a few point you should consider:

HTML Mock-ups: Always create HTML mock ups to define the UI part of an application, show them how will it look like and ask them for their opinions. If you find anything reasonable to change make it happen in the HTML prototype. Using this you will sort out lots of things like UI issues, basic flow and some add ons(like Sorting, Pagination, no. of records to be displayed etc.)


Active Participation from the other end: This is very important if you are developing for a business organisation, get in their business ask them to clarify your doubts and without fail ask them what changes do they want in their flow (if required).


Modular release: Release your code in a modular fashion, release, test, take feedback and release again.

share|improve this answer

Active user involvement throughout the development cycle, and use of as much Agile methodology as possible really helps us with our products.

Spec changes are inevitable, but by being transparent with users and above all, frequently consulting them means most changes are captured as early as possible.

share|improve this answer

For me it's quite easy.
Tell the one, the "Product owner", who have ordered the features that this is OK, but he have to choose a couple of planned feature he could be without for this deadline.
Think of it as a half sprint meeting with the PO where you tell him that the sprint wont burn down to 0.

Ps. If it's not the "PO" I would say don't talk to me go thru the "PO"

share|improve this answer

What are some of the best ways you guys have found to minimize and prevent spec changes from cropping up midway or after development?

There are no best ways. It is up to the management to limit the changes to spec in the certain phase of the development.

However, you should design your software in such a way to expect the changes. Then the impact of changes would be much less. Iterative and incremental development is a good start.

share|improve this answer

I've found that, directly or indirectly, customers are the cause of most changes (and also most critical bugs, BTW). So the obvious solution is to eliminate customers. (What good are they anyway?)

share|improve this answer

Since you cannot prevent change, you need to embrace it. I think the most important thing you can do is: you need to try to get the change requests from the customer as early as possible, because it is less costly to change things when there is only little code. So you need to present your design as early as possible to the customer by using prototypes (perhaps even a paper prototype), use agile methods and so forth.

share|improve this answer

You could consider introducing some discipline in the development process using a methodology like SCRUM. In SCRUM, a team makes an initial plan by splitting the implementation of features into stories, and assigning each story an effort estimate (number of working hours or days needed to implement that story).

If a late change is requested (for a story that's already been implemented) you need to create a new story and estimate the implementation effort for it. Then you can go to your manager (the product owner) and simply explain that the new feature is going to cost that extra time. The project manager then has the responsibility of accepting the extra effort and adjusting the schedule (possibly cancelling other not yet implemented stories).

Even if your team is not going to fully implement SCRUM or another development process, you could at least introduce the planning based on stories, estimate development effort for each story, and adjust the schedule as new stories are requested.

share|improve this answer

http://teddziuba.com/2010/05/why-engineers-hop-jobs.html

I spent too many after-work evenings stressed and unhappy because yet another chap does not understand or care how software business works. I have no problem confronting anyone higher up, but I do not have the backing of my fellow nerds. Having kids is a bitch, eh? I will likely quit soon.

Frankly, I wish programmers in general had more balls. Let's look at this:

"""I don't work for clients who pay money, this is an in-house development team on in-house development websites. So, it's not like I can charge for it or anything. And at the end of the day, we have to try to hit deadlines."""

If you were dealing with a $-paying client and if you covered your ass by having a contract (http://vimeo.com/22053820?utm_source=swissmiss), then changes in spec would cost this client more time AND more money (or potentially same or less time but exponentially more money). Your company is trying to get away with changing the spec without incurring the cost of more time and more money.

In the mean time, trying to hit deadlines causes you and your co-workers UNNECESSARY stress; you cannot spend a quality weekend with friends/family. It really is unnecessary, because whoever is throwing work at you probably do not even know it, which is sad.

My proposed solution: collectively have the balls to confront them and explain that there is no free lunch and everything has cost, that an auto-mechanic would take longer and charge more if specs were changed mid-work, that a contracting agency would take longer and charge more if specs were changed mid-work, and there is a good reason for it. If they are not willing to work with you in a reasonable manner, then you as a group will get up and leave, and they will have to hire developers who can pick up the project where it was left off and deliver on time.

Then there is also a promise of agile development, which implies no hard deadlines.

I am yet to see programmers go on strike, but this would have been something. Incompetent managers are too abundant in software companies. Way too many people want to get something for nothing, on Craigslist or within an actual company. http://teddziuba.com/2011/07/the-craigslist-reverse-programmer-troll.html

Programmers need to have more balls.

share|improve this answer

An approach I have found that works sort-of OK (not with all managers obviously) is "I think I can do that, yes. It depends - how much extra time are you assigning to this project? It's a fairly major change you are requesting."

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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