The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

No chance for improvement

I own a mISV. We are developing a software for a major government department. The deadline is one month and we have to deliver the payroll part. Since the time of original discussion of office employees, the design of schemas and planned screens have changed considerably. We have given a demo of the prototype based on their previous requirements. Still, since the department is getting automated for the first time, the employees themselves are unable to tell about each and every case that comes. I need to understand the business working and invent possibilities and that in return create more requirements.

The planned date is near and design is still not satisfactory. While designing schemas, I (as any other designer) have to keep in mind future aspects so that the program is scalable. Once the first version is delivered and the department's data fills the database, there is no chance for the second version.

In this scenario, please suggest how to deal with such projects and complete on time.
RK Send private email
Thursday, August 30, 2007
On time/to budget/high quality. Pick two.
John Topley Send private email
Thursday, August 30, 2007
It;s probably a bit late for your project, but it is worth noting that Agile methodologies such as Scrum and XP include processes specifically to handle these sort of changes:

The Agile Manifesto includes this statement, which is telling (from

"Welcome changing requirements, even late in
development. Agile processes harness change for
the customer's competitive advantage."

The first two chapters of "Agile Software Development: Principles, Patterns and Practices" by Robert C. Martin contain a very readable introduction to the concepts behind Agile development and how it should work in practice. I particularly like the XP idea of allocating stakeholders a "budget" for requirements/features to be implemented in a given iteration, and then banning them from making further changes until the duration is complete.

Highly recommended. :)
Anna-Jayne Metcalfe Send private email
Thursday, August 30, 2007
Bunch of things would worry me hearing what you are saying, but the big one to my mind is "Once the first version is delivered and the department's data fills the database, there is no chance for the second version".

How can you possibly get it 100% right forever in the first cut & assume it will never change? One constant in business as with life is change.

I would say, stop the feature creep and settle on any design (even if not perfect) right now (or give the client a short & fixed deadline to sign up to). Then implement, not trying to foresee every possible future requirement, but put in place a system so that you can update the database. Databases are malleable with alter queries, so as long as you have the raw data available in some form then you can always perform maintenance upgrades.
Grant Black Send private email
Thursday, August 30, 2007
Whatever it takes, get the requirements locked down for the next 30 days.  Let them know that things can change again after that, but these requirements are fixed and cannot change until day 31.  That will give you some time and let the "ripples" from the design changes level out.
KC Send private email
Thursday, August 30, 2007
There's ALWAYS a chance for a second version -- it's just that you have to add a task to the second version to 'port' the existing data into the new version from the old version.

People do this sort of thing all the time.
Thursday, August 30, 2007
Extreme Programming also has the mantra of "YAGNI" -- as in "You Ain't Gonna Need It!".

Meaning -- if you try too hard to program for future needs, you're gonna be putting in quite a few features that will never be used.  That, or you'll be paralyzed by all the myriad possible needs in the future.

The solution to this is to program for a relatively narrow horizon of need -- what you percieve you need right now, and MAYBE one step beyond.  But don't spend much time on the future.  Once you COMPLETE something, it will become MUCH more obvious what you really need and what is REALLY useful.

For most "future need" perceptions, YAGNI.
Thursday, August 30, 2007
>>How can you possibly get it 100% right forever in the first cut & assume it will never change? One constant in business as with life is change.

Grant - the OP mentions that this is a government department.  It's very common in that situation that
a) the budget allocation is for the initial system delivery with no guarantee of incremental development funding-the department will want 100% because it has to go 'back to the well' to fund updates
b) depending on the department and their legal mandate, they may be used to getting whatever they want, hang the cost
c) it has to 'big bang' - all or nothing

OP - if you really have to turn this thing on in a month, you need to have a come-to-jesus* meeting with your client PM and lock things down until the delivery date.  Or meet with your company's principals and tell them it's about to go in the crapper.

Been there, done that with government clients.  If you don't get realistic expectations set NOW - deliverables & functionality - you're going to have a miserable next few months as you rework the Payroll part while working on the next segment.

From experience, for future iterations,
- try to get prototypes done early - the clerks and others with veto power will not have a clue what they want until they have something to look at. DO NOT fall into the 'functional prototype' trap where it really tries to work.
- plan for 2-3 of these as a lead in to 'final specification'. After 'final', a signed change order with cost *and delivery date* adjustments should be required.  My namesake employer handled these as formal changes to the contract.  Having to go up a level for $$ & schedule slip approval will make them think about how badly they need something.
- there are always one or two people who influence the rest of the workers. Try to get these folks on your side, or at least don't piss them off. An influential lead can make or break your project.  If it's too late for that, involve them heavily in the prototyping-even if they don't like your company, the thing that's going to review has their fingerprints on it & they'll support it for that alone.
- these people are also likely the ones with the 'special case' handling knowledge. Pick their brains mercilessly with 'what happens next?' and 'how would you handle that?' type questions. I found that the TQM 'root cause' technique works well for this.

* i apologise if the reference offends anyone
a former big-fiver Send private email
Thursday, August 30, 2007
I generally agree with the former big fiver but it's also worth pointing out that a month is not a lot of time. No matter how big your staff is, there are some activities that you just cannot speed up. The classic example is that you can't ask nine women to deliver a baby in a single month.

I would take a few hours and determine just how much time you really have to work on features. If it takes one day to perform final testing, one day to get the customer's approval and two days to deploy and install the system on their servers, you really have 26 days, not 30. If you work standard five day weeks, that's 16 days, not 20. (September only has four work weeks in it.) Either way, that's a lot of man-hours that you won't have available to squeeze in an extra feature or two.

Once you've determined how many actual days (and man hours) you have available, determine if you can accomplish what the customer NEEDS during that time frame. I would believe the number one priority is being able to print checks with the correct deductions. Everything else, including balancing the books, pre-approving the checks and applying cute little teddy bear stamps, can all be worked around, using pen and paper if necessary.

Assuming for the stake of argument you've figured out that it takes ten days to get the checks portion of the system built and you have six days left, then go back and ask the customer "what is the next highest priority on your list that can be accomplished in six days?"

Slight correction. Don't wait til you've finished the checks to ask the customer. Figure out how much time you need and then ask the customer NOW. Depending on what they want, you may be able to kill two birds with one stone - for example, they may want an option to print checks in descending dollar amounts so that the first check they see (and sign) is the one with the biggest payout.

The important thing is to honestly assess what you will be able to provide and get them thinking about their priorities. If they refuse to spend the time figuring out what they really want, make it absolutely clear, in writing, that you'll give them what they NEED (assuming you can) and you're going to wait to give them everything else they want because they couldn't make a decision in time. In other words, you're locking down the requirements and they can't change them without paying you a lot of extra money and allowing extra time.
Thursday, August 30, 2007
30 days from delivery on a large govenment payroll package and you still do not have final requirements.  Who is the bigger fool - the customer or the contractor?

Thursday, August 30, 2007
I don't care how AGILE!!!!111!!one!1 you are.  If you've spent 3 months working on your amazing new payroll system (dear god in heaven, another one???), if the customer comes to you in the last month and says "oh, we have a new requirement, it needs to also be able to translate our swahili documents into klingon", you don't have enough time to change direction and still meet the deadline.

(Yes, if new requirements also include a new deadline you're fine - but for god's sake, even the waterfall fans can adapt to change if you give them an extended deadline.)

And I have a suggestion for the OP - when you have the "come to jesus" meeting, you may want to take the "pray for a miracle" bit literally - it's your best hope. The last month is when you're supposed to be finishing your last-minute testing and minor tweaks. If you've left yourself only a month for major design and implementation to be finished then you haven't left enough time to check for all the subtle bugs that you know for a fact still exist.

"One day for final testing" ??  Huh?  And people wonder why software is often so crappy.

Hell, I know we're crying like babies about the evils of government here, but two private companies can take a month or more just to negotiate the meeting to consider discussing a preliminary spec. I really don't get some people.

How to handle this situation?  Don't get into it in the first place.  And if you do get into it, don't be surprised when it all goes hideously wrong.

(The best you can hope for is to barely meet your minimum contractual obligations - so go over that contract carefully and do what you have to so you won't lose your business and after that, worry about all the other good suggestions here.)

Thursday, August 30, 2007
"'One day for final testing' ??  Huh?  And people wonder why software is often so crappy.

Heh. Since I wrote the original, I'll respond and hopefully clarify that.

Assuming that you have unit tests, a testing script, or an extremely detailed test plan, "final testing" involves you doing everything on that list from begining to end and making sure you haven't missed anything. More importantly, you have already found and fixed every bug that's been identified through normal usage; you're more worried about one of your fixes breaking something else.

In the ideal scenario, you basically start your comprehensive build script complete with unit tests covering everything under the sun, go off and have a nice leisurely lunch, come back, see all of the tests pass, and burn the resulting binary executable to a gold master.

This also means that as you develop the product, you should be testing it as you go along. If it takes ten days to build your payroll system, those ten days should include the time you spend testing and debugging your work. If you have a quality assurance team, you need to budget that time as well.

Maybe there's a better industry term for the final test.
Friday, August 31, 2007
"Maybe there's a better industry term for the final test."

I would call it an acceptance test; basically a final run through to prove that all the testing to take has been done and pasted. Its a show & tell demo more that a test, because you don't expect to find any issues; if you do then its too late to go back into a fix cycle.

I think you seriously need more testing before then though - including some with re-world data and users, (i.e some beta testing) as something that has been well unit tested can still break badly when you get some odd-ball machine config that you haven't found.

BTW - XP service pack 2 just came out with support for a Maori locale. It's new & so I switched over to the locale (not that I know enough Maori language) & found that one of my applications died on every run due to an underlying 3rd party component that silently fails on some oddball locales. You just can't plan for this stuff ;-(
Grant Black Send private email
Sunday, September 09, 2007

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz