Slashdot Mirror
Giving the Customer What They Wanted?
"Sometimes these different views can result in almost funny situations:
Back in the stone age of programming, we had a customer who wanted to have the result of a database query sorted by a specific field ('usable' databases at that time were either incredibly expensive or simply unavailable, so we had created our own proprietary database). He asked for this because the old software they were using could do this. However, we couldn't, and everyone was horrified by the thought of programming this 'ASAP' but we were ready to do it.
Eventually we talked to him and asked him what exactly he wanted this for. It turned out that he didn't even want a sorted list. He wanted look for a specific value in that field (something the old software couldn't do), and he got it by looking at the sorted query results. Our software, however, was capable of searching for field values already and return matching results only.
At this point both parts were happy: he got what he wanted and we didn't have to write a single line of code.
Of course, there will always be the geek with the 'use-it-my-way-or-f*ck-off'-attitude. For me however, talking to customers and trying to understand what they want (as opposed to what they tell you) was always a big part of what made developing software fun and satisfying.
So, how often did you find yourself in a similar situation?"
This is why software evolves, and this is the power of extreme programming and rapid prototyping approaches to software development. You try to get a good idea up front what the customer wants, but then you build stuff really fast and show them something. Then they can try it and see what they think of it. You will find that new requirements pop up and old ones disappear.
If you're not a lone coder, who is able to make up his own spec and make sure the software can do what the customer wants, the only time you meet the customer is when the sales rep has completely fubared the job, and he and your boss and the customer are all screaming for your head. This is a very common problem for large shops, where a middle man who can barely code is speccing the job out, and is why the spec winds up being revised every few weeks.
That this was one of the main reason Extreme Programming was invented.
Buy a Nintendo DS Lite
Trying to resist the urge to throw in the obligatory Office Space reference...
What I'm listening to now on Pandora...
I'm an independent web developer, and as such I have a one on one relationship with the (non-technical) people who dictate the 'features' of the software I produce. Most of the time I'm doing not-so-glorified copy editing, but when I do have to create a maintenance tool or a more dynamic feature on the sites I work with, I find that I start to come up against what I perceive as a certain technical ignorance on their part--which is really a lack of communication between the two parties. Many times we'll get to a certain stage with a project, and our mutual assumptions will all of a sudden rear their ugly heads. Me: "Oh, didn't you realize that javascript/perl/unix/the current state of computer science and physics/etc. won't let me blah-dy blah blah?" Them: "Oh, didn't you realize that if you were going to build that thing it was necessarily going to have that feature because that's just a given?"
Having the relationship with my clients that I do, I find most of these problems pretty easy to solve; talk it through, try to understand what they really want, express the issues involved with implementation in as non-patronizing and non-technical a manner as possible. The most difficult point for me though is the debate between feeding the customers the line "that's not technically feasible" or trying to figure out some way to get what they want. I've found that 9 times out of 10 it's the case that I can do what they want if I push and prod myself a bit harder. What's even harder is those times when it's a balance between what the customer needs, what they are willing to pay for, and how long it might take me to do something, and I'm really not clear how it might all play out. An interesting problem.
I would also imagine that my personal solution to this problem wouldn't scale very well if you shifted it to a team of programmers working with a marketing department, customer service department, etc. My "organization's" small size is what enables me to solve these problems quickly and easily.
Sorry I've not supplied any real specifics, I really shouldn't; just wanted to comment on this issue because I definitely find it personally relevant.
I think it is always unreasonable for either person to do the other's job: that is why there are two people there. Nothing gets an enduser more upset than not being able to do what he wants - being forced to do something one way because the programmer likes it doesn't cut it.
At the same time, the enduser shouldn't try to write the software! Instead, describing what the user would want to do with the software, discussing it with the programmer, and letting the programmer decide the best way to implement it should be how it is done....I've yet to see it happen well, though. Both sides have egos to protect, it seems. The endusers are dumb and don't know what they want; the programmers don't understand what the enduser wants to do or why he needs it.
The biggest complaint seems to be feature-creep or missed specifications because the enduser wasn't aware of what he wanted. This is where programmers typically need help, it seems. The figuring out what the customer wants and finding out how to implement seems to be a very low priority for most programmers...
One person whispers a short phrase into someone's ear who then passes it along in the same manner to another person, until the phrase gets transcribed by all people in the room, and the oft-hilarious result then disclosed.
I've often thought software development is like that.
Unless you're contracting directly with the customer, and note the requirements in his/her words, translating them to a technical equivalent (and, of course, translating back, and making sure you got the jist of what he/she wanted), you run the risk of these translation problems.
Often, such insulating layers are placed between well-meaning programmers and the customer to make sure they don't try to deliver more "work" than what the customer is willing to buy. This gets difficult because the programmer where the buck ends is expected to make the customer happy, but to spend the least amount of time possible on it, so that he/she can be assigned to the next project.
I've always thought that was a bad idea. Novice programmers' enthusiasm can be restrained by senior project leaders who might actually be the contact point with a customer -- they're called "systems analysts" for a reason -- the supposed ability to translate human-speak into technical requirements and estimate the work to be done.
In an ideal world, this estimate would be returned back to the customer via sales and a human-speak description of the work to marketting so they can get a feel what piece of it might be reusable on other projects and to feel the pulse of market desire.
More likely, much of this initial analysis is done by people not qualified to do it (sales and marketting types, though technically savvy people do exist in such roles), and critical customer requirements are either lost or not questioned.
I've been in situations where a customer's technical team rejected outright our technical proposals purely because of miscommunication across our respective management hierarchies. I've also been in situations where such miscommunication finally gave way to both technical groups getting together to convey an understanding of what's really wanted, usually after wasting much time and money. Often, in such meetings, one can almost feel the light bulbs finally turning on above the heads of those responsible for the confusion: "Oh! So when you said you wanted it ON a hard disk, you meant INSTALLED on the hard disk in the system, say, from a CDROM, and not DELIVERED that way!!" In all fairness I can see both ways being legitimate software delivery systems (the latter particularly if you're serving as hardware integrater too), but it is important to recognize the ambiguity and resolve it early.
What I've found works is a close technical liason to define the work to do, but, of course, no programmer delivers anything except through official channels, which are gated by the money stream.
You could've hired me.
No, seriously, depends on teh company. SOme companies do and some don't. Usually I b&m till I get a conference call if I am to confused.
Only 'flamers' flame!
You should take a look at a software engineering course and a few books.
They describe exactly what you are talking about, from writing specs to implementation. From forming teams, to prototyping a product before you start doing the hard parts.
-
ping -f 255.255.255.255 # if only
As one other poster pointed out the customer may not really know what they want. They may have a vague idea, but haven't really thought about it thorougly enough. I see this sometimes when I'm talking to customers when you say "well what about X?" And this little light goes on inside their heads about some aspect of the system they'd never considered before, and reams of new requirements come spewing forth. If it is a time+materials project I try and work with them to fit the new requirements in to their budget, if it's fixed price they can sometimes get nasty and say they just "assumed it would be covered because Blah works that way" or some other nonsense when both of you are quite aware that up until 5 minutes ago they'd never even thought about it.
Another classic problem I've seen is when a "typical user" is chosen. Often this person is NOT a typical user of the system, they are the manager of a typical user, or a business analyst that "knows this area inside out". Politely listen to what this person has to say, and then go and find out what the _REAL_ users of the system think.
Another common defect is the "one line paradox specification". It goes a little something like this...."The new system should work exactly like the existing system, only better, and over the web".
Another common problem is the "user as frustrated interface desinger".. where a user will come up with very wild/unconventional/impossible ideas as to how items in the user interface should function. This is somewhat related to the "typical user" problem. This users crazy interface requirements might be possible, but you will end up building a system only they could like or even use.
Another problem is "users expectations completely out of synch with budget"..you have a budget for X hours, but the users have no idea of this and will run wild with features that will make their lives easier(if the project doesn't get canned beforehand), or playing amatuer graphic designer, screen layout games. Make not of all their suggestions but make sure you run by all the features they suggest with someone who is paying for what you are doing before you go and implement them.
Overall I would say that ineraction with users is great, but beware that the "user"
That has to be the worst thing a client can say to us. Things are better now in the web business but in the last couple years we couldn't just tell the client to fuck off if they deviated from the signed definition of "done".
The second worst is: "The CEO who has never even cared about the website until now finally looked at and he hates the color blue." This is after 3 months of building an e-commerece site.
Hollow words will burn and hollow men will burn.
As is the general case, the customer is an idiot. Why? Well, instead of giving the techie the problem ands asking for a solution, they think up their own uneducated answer and ask for implementation. Then, when questions arise, both the programmer and the client fumble in the dark.
First thing to do is to ask the client what the problem is. If the answer starts off with "I need", grimace and ask again. Tell them pleasantly but sternly two things. One, that you will give them anything they ask for. Two, it is best to give you the problem, not the answer.
Now, on the programmers part two things are sorely overlooked. They are the requirement and the specifications. They are two very different things. There can be only one requirements document per project, as it details the requirements. There are many possible specification documents, because the specification is one solution.
After the programmer has a basic idea of what the problem is, the programmer should write a requirements documents. This should go through *at least* three rounds. If the original requirements document is said to be good, than the client is probably not willing to put in the effort neeeded to think about it. Explain to them the importance. You'd have to be incredibly lucky to get it right the first time around. Youy know you're done when the client says "wow". Finally, the client *must* agree that these are the requirements for the project. At this point, the fee and basic estimation is done.
Now, the client is not really needed. The problem is understood, and is clearly spelled out into an agreed upon requirements document. Now comes the solution. Think up one and write a specification document. Depending on how much the client needs to know should decide whether to share this with the client. There generally is no need, and they don't care how it's done, just that it works.
When work is up to specification, match it to the requirements, and go through it point by point with the client. Voila, done.
Have you read my journal today?
I had a manager, I'll call him Dr. B, who knew next to nothing about anything IT related. But Dr. B. was an ex-professor, had a doctorate in biology, and had a brother who was a programmer. Biggest blowhard and control freak I have ever met. Dr. B. simply could not help but insert himself into every aspect of every effort. He simply could not back off, even when given a direct order by the CEO not to get involved and not to introduce feature creep. The entire group (bioinformatics) was finally removed from under his supervision... and still he managed to bog us down. I finally left for a more reasonable work environment. I have been designing a much better system as therapy and will open source it as revenge! (twitter-flinch-shake)
First entomology, then virology, and finally bioinformatics systems. Bugs follow me wherever I go.
There's a job called 'systems analyst' that covers this. Back in the 80s I was one (later I became a programmer). The job was to act as liaison between the customer (user) and the computer people, and speak both their languages.
System analysts then make up the design documents (called a 'functional requirements') for the programming team and customers to serve as the 'treaty' (or battle plan, if you like).
It's a profession that may have fallen out of favor in rapid startups, I guess-- isn't edgy enough. It's essential for any good project, but too many people are in a hurry and do the usual "I'll write up the requirements while you start coding, go!"
A.
example:
Use Case For the "View of Contact Addresses"
Actor: user
Preconditions: there are at least one contact in the database
Motivation: Actor wants to locate a pacticular address
Outcome: Actor locates particular address
Step 1) (left blank until you agree on the above)
Step 2) (blank)
Step 3) (blank)
If you *start* with this, than you and the client have a lot of wriggle room as to how you finish the use case. with a sortable tree? or a text input that looks up contacts by name? it doesn't really matter as long you both agree to the above.
too often, the two parties talk to each other and both come away with two entirely different ideas of what the use case is. if you come up with a really basic use case (like above), *write it down* and pass it to the client for review, you've saved yourself a ton of work.
There aint no pancake so thin it doesn't have two sides.
Well, how often do you talk to the customer? Depends upon how big the company is. It's broken down into one of two scenarios:
Large company: You will never talk to the customer. Any communication between you and the customer will pass through at least five people who will all either add in their comments, edit text at whim "to make things clearer", or just make stuff up out of the blue.
Small company: You will always talk to the customer. In fact, you will never avoid being able to talk to the customer, even if you have four other projects that need to be done by end of day.
No, I'm not cynical. Why do you ask?
How to deliver a damn good kicking:
Step 1: Perform an on-site visit to the customer
Step 2: Drop a briefcase full of papers
Step 3: Kick 'em as they stoop to pick them up
Success! You have delivered exactly what the customer needs.
Of course, if they don't need a damn good kicking at the moment, save these instructions - you'll want to add it to the feature list at some point.
Every cloud has a silver lining (except for the mushroom shaped ones, which have a lining of Iridium & Strontium 90)
I've almost never met a customer who actually knew what they wanted. At least, not consciously; but over the years you learn different ways to pry information out of them... sometimes it takes visual aids (in the form of an interface mockup to look at), or lengthy meetings, or in extreme cases a hammer and chisel, but I've never had a project where the actual coding was anywhere near the bulk of the work.
h alf.ht ml
Unless you're part of a team working in a large organization, the job of programmer is less than half technical IMHO. As a freelancer, I feel my value to the customer lies more in my years of experience working with non-technical end users than it does in my understanding of a particular language or platform. Of course, that's tough to get across to someone you're trying to get work from...
The problem I'm having with my current main project - a customized time-tracking application - has more to do with requirements-creep. The customer (a state government agency) keeps coming up with strange and irrelevant types of information they want gathered along with the stuff that is actually necessary for the research. Fortunately, I'm just a subcontractor in this case; there's a layer between me and the client, and it's those people who are really suffering from their behavior since they'll have to figure out how to cope with this non-orthogonal information while compiling the report. All I have to do is keep adding more buttons and forms, periodically reminding them how much more complicated and intimidating the interface is becoming and how far past our original budget we are... it's actually nicer than a lot of other jobs I've had.
Another sideline I have is doing websites for friends in the entertainment industry. One site I've been trying to get started on for over a year now is for a comedian who, by his own report, is so bad at self-promotion that he freezes up when the emcee asks how he wants to be introduced! So this has been a long, hard slog to get anything out of him to put online...
Anyhow, enough rambling. The point is - helping the customer to figure out what they actually need is the unspoken part of the business that they don't teach you about at school. It's more than just leaving the jargon out of your conversation, and it's a skill too few of us have developed.
This pretty much says it all:
http://www.netfunny.com/rhf/jokes/91q4/prog
Perfectly Normal Industries
Giving the customer what they asked for instead of what they wanted? That's a paddling!
One site I've been trying to get started on for over a year now is for a comedian who, by his own report, is so bad at self-promotion that he freezes up when the emcee asks how he wants to be introduced! So this has been a long, hard slog to get anything out of him to put online...
Now that's funny!
While working as a *NIX consultant for the now defunct Aperian a customer asked for a load test of a web server. The "technical sales" guy (Who BTW was reasonably technical, quite smart, and not a dick at all. Almost changed my opinion of "technical sales guys.") delivered the marching orders to me.
He said that they wanted a load test in the middle of the night so as to minimize the effect of having customers not be able to access the box. I don't remember all of the instuctions but I remember the phrase "crater it" and "crater the box" were used (by the sales guy).
So, at midnight the cron job dutifully kicked off the Siege. I wasn't being paid overtime for this, so I damn sure wasn't going to babysit it from midnight to three AM. I did get up (briefly) at three to make sure that the Siege had stopped as scheduled.
The next day the customer was livid. As it turns out this was an NT box. I hadn't been told this, and I didn't really think it was relevent to my thrughput numbers. The customer was PISSED because "we kept crashing his box" all night.
I don't know what the moral is. Maybe it is "get in the same room with the sales guy and the customer before doing anything . . . drastic." I don't know.
If any of the old Outernet/Aperian crew are reading this, mail me!
-Peter
I think the story in the article really illustrates one of the most important things about giving the customers what they want quite beautifully.
Don't let the customer just hand you requirements. By virtue of the fact that they are coming to your firm for help, it is fairly safe to assume that they aren't experts on the kind of product you are producing for them. Because of this, they probably don't know enough jargon or have enough knowledge to translate all their ultimate goals into a good list of requirements.
When the customer says, "this product also has to do foo," make absolutely sure you ask them why they want it to do foo and what place activity foo has in the process of getting whatever productive work they want out of the software to be done.
Another classic example: professor goes to a computer lab attendant with a few sheets of paper, and asks them to be scanned. The student scans them and hands them to the professor as Photoshop images. The professor takes them back to her computer & tries to load them up, but doesn't have photoshop, so she can't load them. She calls the help desk, & the helpdesk helps her install photoshop.
Then she complains that she can't edit the text in the images, and ends up going through a crash course on editing images on Photoshop. Only after all of this happens does someone get around to realizing that since the papers were all text documents, she probably wanted them run through OCR and handed to her as Word documents, not image files.
Two things that are in common:
customers many times ask for a feature rather than explaining why or what they want
developers tend to design things that are useful or interesting to them and not the customer
The only solution that seems to help is to find a middle ground language and/or person to bridge the gap. Prototypes of any sort seem to be the most effective, especially when trying to introduce a customer to a new concept.
The main point I'm trying to make is that there may be some useful information from Product Development books and courses that are not aimed at software development.
Written Use Cases, until I saw and used them, thought they were a silly waste of time. Now I've used them and think they are indispensible for facilitating communication between the business and technical disciplines.
This is NOT UML!
Business Subject Matter Experts write the Cases, at the least the high-level ones, forcing them to really think out what they want and how it should work.
I recommend "Writing Effective Use Cases" by Alistair Cockburn. After looking at several resources, this is the only book I've found focusing exclusively on this area, and one I have found useful.
Because of this the best way to develop software is prototyping. I strongly believe this.
Extreme Programming, Rational Unified Process, MS Solutions Framework... with little variation they believe in small iterations and phases.
Prototype, prototype, prototype!
Work with your customers!
Prototypes aren't just good for testing the feasability of your technical ideas. I like to bring my software to the users often throughout it's development. Just like Free Software...release early, and release often. I get valuable feedback before I spend too much time on features they don't like.
That said... this needs to be done PROPERLY, or you will become enslaven to users who just don't understand software development. You need to make users understand up front that they are going to have to take your word on it when you say NO (and you NEED to learn to say NO), else you will spend forever explaining to them why it would not be possible/cost effective to do it their way.
My website is http://www.chrisranjana.com and I do php perl freelance work and I have felt the same way a numerous times.
1) isn't web designing included in your quote I thought it was default ?
2) oh for making changes in those user options I thought there is going to be an admin panel by default ?
so what is the best way to solve all these issues
Chris ,
Php Programmers.
Customers (not necessarily end-users but same thing applies to them) are unable to accurately specify their needs. This is not a problem, but just be aware that this happens a lot.
The customer is not an evilly whimsical person. He usually has needs that he tries to formulate by stating a possible solution. This is a natural reaction, since people solve problems with solutions. Only, it's not the customer's job (and often not in his ability) to specify a good solution: this is the job of either a "system analyst" or the programmer, depending on size of assignment etc. This is the reason that customers seem to change their minds on a whim, the "That's not it, but I'll know it when I see it" attitude. He's doing his best to help you, but in the process is misrepresenting the problem he has and actually making it harder for you to come up with the right solution.
Bottom line: good software people help the customer formulate their problem. It's an essential part of the job!
Most of the time, we're lucky if we ever get contact with the client before the Sales department have agreed completely unfeasible project specifications, and equally unfeasible deadlines.
In the cases where we do get involved before a project starts, the customer almost always ends up with exactly what they want (and more) - if we're not involved, the customer almost always ends up disappointed and doesn't get half of what he actually wanted.
Life is like a sewer; what you get out of it depends on what you put into it...
Job one:
Left to fend for self infront of 1,000 customers on a daily basis supporting legacy software that was hacked together by a boss's son during his summer vacations from Junior Highschool totaling 50,000 lines of bad PERL code. Daily interacted with the customer, typically them screaming about broken code that wasn't actually broken. By tracing their work-flow and documenting it I was able to redesign their software systems to match their actually desired work flow. Took a year of hard work.
Job two:
Sales staff secured sales for e-commerce solutions. Given parameters of requirements and total budget provide a timely solution. Interacted with the customer to determine if the end product was satisfactory. Frequent over and under budget problems.
Job three:
Highly structured requirements, testing, and sales structure. I'm handed requirements that have been reviewed for at least a year. Each product must fit the requirements. No interaction with the customer at all. Except, I'm special and I do both troubleshooting and developement. I don't control what I develop and I still am responsible for fixing it.
Each job has been progressively worse. Each time management has been more and more clueless. Each time I've had fewer and fewer inputs into what code to fix and where to spend development time and energy. Job three is a total fiasco. I can't fix the problems I find without management approval and management would prefer I develop new features even if none are needed. Features make money, bug fixes don't.
Software is hell.
but it's not worth it. I used to try to make small changes to what they asked for because I knew they didn't think of everything and they didn't want to be questioned (or I wasn't allowed to question them), but I gave up for the most part. I find now that if I do exactly what they ask for, they get, well, exactly what they ask for, and next time they're a little more cautious and detailed about it - plus I stress less over the task at hand and I won't get in trouble for doing something "different".
I do still question things from time to time where our data integrity or security could be compromised (and then hear "oh yeah, I didn't think about that"), but that's about it.
It's been my experience that customers do know what they want. However, most often their frame of reference is their existing work process and supporting software. Typically, customers expect new software to alleviate specific annoyances in their current environment, but they have little insight into how new software might transform their working environment. Developers should bring that insight to the effort, but, again typically, are disinclined to study the customer, preferring to go off to their cubicles and code to a requirements document. Inevitably, someone in the customer camp begins to get a clue, prompting changes to the requirements.
Requirements should be written by techies who have actually worked alongside the customers long enough to understand what it is their are really trying to do. The author of the requirements should be required to explain them, in lay terms, to the customers, to ensure that both sides think they mean the same thing. And, foremost, both the customer and the tech staff must designate one individual each -- someone who has at least a passing acquiantance with the other's working environment -- to act as a translator, a bridge, between the communities.
-- Slashdot: When Public Access TV Says "No"
I usually put together a spread sheet of use cases, what currently hapens, in the case of a bug or automating a process and what should happen.
There's then a bit a back and forth, itterating over the processes until both the user and I understand what's going on.
If the user asks for something then I will always re-write it in my own words and get the user to confirm that this is the case.
an example may be
Process:
MTA's with an MTA between the current risk and the time of the MTA
e.g. A customer asks for his wife to be put on the policy in a weeks time and then a change of vehicle in two weeks time, the aditional driver MTA is in-between the current risk and the COV.
Resolution:
an MTA must use the risk at it's effective date, if the in-between MTA is deleted, it must delete all MTA's after it.
user comment 1:
Is this not the same as CLX003 ? If not further detail required[CLX003 being another process listed on the sheet]
response: (use case, a bit more detailed than the first)
A customer phones up and asks for his wife to be put on the policy in a weeks time. A couple of days later he says he's moving house in 2 weeks time:The first MTA is actioned 'between' the current risk and the second.
the use cases are also good for testing.
thank God the internet isn't a human right.
Good point. On a sidenote why do people bother to post 'please mod the parent post up' messages? The AC post is much more insightful than the parent.
These solutions all work because they recognise that the specification is a shifting target and so they seek to minimise the cost of change. If you know that the customer is going to change his mind in three weeks time then make the quickest change that you can to satisfy him, knowing that it will be gutted and rewritten several times. Quite different to the NASA school of programming where the spec (please don't blow up, oh god please don't blow up!) doesn't ever change so they invest time in doing it right first time rather than chasing a changing target.
Slashdot: where don knuth is an idiot because he cant grasp the awesome power of php
Giving the customer what they want isn't always possible. Reasons can be but not limited to product limitations, money, time, motivation.
I have been on a couple projects where the salespeople promise customer that our product can do everything under the sun. So when we consultants show up to the customer site, we have re-align the customer's goals to what is feasible. That puts us in a horrible starting position because the customer is all upset that they aren't getting what they were promised.
And then there is scope creeping. If your project is fixed priced, you better have a capable PM that can say "NO!!!!!!!" to the customer when they request new things. Otherwise, the company/project is going to lose money and is doomed to fail.
I often tell our support people to ask the customer what do they want to not and not to just answer there question. This is a prime example of that.
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
This affects the way clients describe what are their needs to programmers. And after they see the prototype or alpha version, their imagination begins to plot changes to the original plan. "Please add a new report here, change this database field; Port it HP-UX, OS X, and Solaris. All you have to do is to change a little bit the code... Right? Can this be ready by tomorrow so I can show it at the meeting?"
Netudo
You would think that describing business rules in a logical, unambiguous manner is a matter of common sense. However, after dealing with my share of users I have come to realize that it is a great skill--and is a good chunk of the reason we get paid so much.
I'll never forget the time we spent weeks trying to figure out this one business rule for a system that tracked Employee's Sick Leave Credits. We'd go to meetings with the users and think we have it. Then we'd realize later why it didn't quite make sense and bring it up at the next meeting. Finally turned out to be that, to them, when an employee was 'away' they were absent without credits, while we thought that that when an employee was 'away' they were just absent.
With apporpriate tools and reuse libraries, coding really truly is the least important part of the Software Development Life Cycle.
I work on large scale implementations and upgrades - 12 months, '000s of man-months, multi-million $ budget etc. FWIW, my bible is The Mythical man-Month. It is less relevant, but still usefull, for smaller (say 3 months, 1/2 million labour budget) projects.
Plan, Plan, and when you're sick of planning, plan some more. Both you and the customer review the plan, till you both know it off by heart.
By this time, you and the customer have written the system. Now you just have to translate it into the platform / language of their choice.
to summarise (stolen (sorry -researched- )from The Mythical man Month):
1/3 planning
1/6 coding
1/4 component testing
1/4 system test
there's nothing new about this - my projects fail when I ignore the lessons I've learnt - they work (on budget, on time, on spec) when I follow the lessons I've learnt.
We specialize in building automation systems that give the building accopants what they want (perfect office temperature control, humidity, etc) with the least amount of energy. We often have to justify our work by a measurable reduction in the customers energy bills.
Of course, I'm a complete geek, I had no experience in how these systems worked, or how tight you need to control an enviroment.
My solution was to not really listen to my mentor (a HVAC tech) when it came to the actual coding. But to make sure I worked right along side of him on every part of the installation and maintainence of the machinery.
This has had several results. First, I am picking metal slivers out of my fingers this morning after a really nasty fan rebuild yesterday. :) Second, I've become a halfway decent HVAC tech, with the corrisponding increase in systems knowledge. Third, I can now pick up a book on energy management and actually understand it. But most importantly, the systems that I have been writing code for keep tighter control and cost less to run.
In short, don't be afraid to get your hands dirty when you're finding out what the customer wants. Take the time to talk to a sampling of the people that are going to interact with your product. It'll save you LOTS of time on the back end.