|
Depends on who the work is for...
That is very very true!
Very very very true in fact.
Nish
Sonork ID 100.9786 voidmain
www.busterboy.org
If you don't find me on CP, I'll be at Bob's HungOut
|
|
|
|
|
Chris Losinger wrote:
- tell me exactly what you want; if you don't, you won't get it.
I believe customers NEVER know what they really want
Mazy
You can find a solution (even a foolish one) for all problems (even big ones)
|
|
|
|
|
That is very often true. The key factor is to spend as much time on the specification side, making it as detailed as possible so the customer knows what they are going to get. My current project went through 17 specification revisions before I was happy to start coding. The customer is a lot happier too because she can see what she knows what she's going to get.
Michael 
|
|
|
|
|
What do you consider design and planning and to be?
Do you design down to the function level, or just at the class level. Do you design each function that will go into a class or do you just plan the public members and then write internal functions on the fly as you need them?
Michael
|
|
|
|
|
Id say you need to design the core functionality, and pay particular attention to how different classes/components will interact with one another and finalise protocol decisions. Designs shouldn’t necessarily go right down into each member function, that’s the job of coding, but should say which primary functions are going to exist and what they will do.
|
|
|
|
|
The question should be extended to 'what constitutes a design'. Is a prototype a good design? Mockup screenshots? User manual? Annotated pseudocode? UML diagrams?
Personally, I find that tweakable throwaway code makes the best possible design - it's verifyable at least as much as paper-based designs are; As opposed to english/paper/UML based designs, it can be reviewed/verifed by anyone (most importantly, your client!). It actually lets you reason further, e.g. measuring for bottlenecks in some cases.
If done right, it can be gradually replaced by the real thing, which would give something verifyable observable at any moment. However, care must be taken that throwaway code is identified as such - more often than not, someone higher up in management will tell you "Well, it's already working, tweak it a bit over here and there, and let's ship it" - often setting the schedules accordingly so that you can't do anything otherwise. Steve McConnell's advice for this (which I whole heartedly support) is MAKE SURE THAT CAN'T HAPPEN. e.g., by prototyping a Windows application with HyperCard on a Mac; Or using a language that will be disallowed as the actual implementation language such as Lisp or Prolog.
80% of software projects fail to meet deadlines or requirements. This is due to the optimistic nature of programmers on one hand, and to ill-defined requirements on the other. Neither can be solved by good will (and perhaps not at all) - the development process has to take both of these into account. An iterative development process with "working" prototypes, goes a long way to accomodate both.
If you don't have experience in rapid prototyping, take a month off work, and develop that experience. An experienced prototyper can crank up an IDE or a new language implementation in a week without building on highly specialized components/tools. If you're experienced, it takes more (though not much more) time than writing the specs, but it's thousands of times more effective.
|
|
|
|
|
As developers we often overlook things that get in the way of our coding, but an app built without a design is a doomed app! I work for a software house that doesn't design, properly test or properly manage its products' development, and, as a result, the core of my work is based on fixing former developers poor quality code that has lead to some nasty problems (and therefore cash being wasted by the company). It angers me beyond believe, if only management stopped and thought about it: a properly designed solution to a given problem will save money on testing, correction, maintenance and in the end will make sure your customers and developers don't bugger off to the competition.
It's worth remembering that 'quality' is something users aren't really aware of when it's present, but are only too aware of when its missing, and the only way to guaranty quality is to do things properly.
It's this complete lack of project management here that is making me think about changing companies – so if anyone's looking for a coder in London....
Dylan Kenneally
Software Engineer
|
|
|
|
|
There is a reason why the average 747 costs many millions of dollars. The answer ain't the price of aluminum. The reason is that thing has to be perfect. It takes thousands of engineers many years to make the machine perfect.
The complexity of any software application increases exponentially with the size. Even a relatively modest application probably manages about as many objects as there are parts on the average 747. If a company were to take the time to make that application perfect it would take a decade to finish and it would have to be sold for something on the order of $100,000,000.
But the typical application does not have to be that perfect. No one is going to die if it malfunctions. So you do not have to produce a perfect app. It should be as perfect as you can make it in a reasonable amount of time with a reasonsable amount of expense, but perfect? No way.
What the customer has the right to expect is not a bug free application. Rather, the custmer has the right to expect an application that is supported, support that provides for the quick and effective elimination of any bug, once discovered.
So, the notion that anything other than small, in-house or web based applications, are going to be subjected to thorough design review and lengthy specification processes is ludicrous. It ain't gonna happen. In the real world it can't happen.
"Thank you, thank you very much" Elvis.
|
|
|
|
|
Can't agree more. Another thing is, if there is no design for a project you are told to work on, are you willing to quit the job if nobody is responding to your request of a formal design?
|
|
|
|
|
In certain situations, hell yes.
If someone wants me to write some code that could potentially fail and cause damage to something/someone, and if that someone doesn't recognize the need for formal design, then there's no friggin way I'm going to put my name on it.
J
|
|
|
|
|
Air traffic control software..........
Have a look here.
Giles
|
|
|
|
|
When it comes to software which lives *do* depend on, obviously no expense should be spared. It should be as secure as is humanly possible.
"Thank you, thank you very much" Elvis.
|
|
|
|
|
Stan Shannon wrote:
So, the notion that anything other than small, in-house or web based applications, are going to be subjected to thorough design review and lengthy specification processes is ludicrous. It ain't gonna happen. In the real world it can't happen.
I have to disagree.
The IT industry has a bad attitude of "look, no one will die if this thing crashes, so lets skip the design phase." The problem with this attitude is that it "seeps" into everything else. The coders see that the management a design team don't care that much so the coder produces sub standard code. The testers then see that the coder is not very worried, so they don't worry and let through all sorts of rubbish.
I totally agree that it is impossible to create a perfect product. No matter what it is, from a hammer to a 747 to a computer programme. They all have faults and defects, bar none.
Also you should not strive for perfection, as it is a resource wasting process. Rather you should strive to provide a solution that works and as you say provide support for unexpected eventualities. Remember if everyone thinks "oh leave the bug and lets get a pint, the support guys can handle that when it is found" just makes for a sub-par product, something you would not be proud of and your customer would not be happy with.
All in all you need to set the expectations of your customer. Put in a bug and testing phase and admit that no matter what you do there will be bugs and problems. But those are more for "syntax" bugs than "design" bugs. 90% of all design bugs can be ironed out with a good design. We have found you do save time by desinging up front.
For example we along with another company quoted for the same project. We included a design phase of 3 weeks, the other company did not. However their development time was 3 weeks longer than ours. We knew we could do it quicker because we would have a stable design to work from.
Stan Shannon wrote:
It should be as perfect as you can make it in a reasonable amount of time with a reasonsable amount of expense, but perfect? No way.
Exactly right. If the customer insists on low cost (which equals short development time) then you make sure they choose between quality or quantity.
regards,
Paul Watson
Bluegrass
Cape Town, South Africa
"The greatest thing you will ever learn is to love, and be loved in return" - Moulin Rouge
Martin Marvinski wrote:
Unfortunatly Deep Throat isn't my cup of tea
Do you Sonork? I do! 100.9903 Stormfront
|
|
|
|
|
Don't people die? Modern business relies entirely on our systems and our code. If businesses fail, people lose their jobs, can't feed their families, experience financial hardship which leads to stress, which, as everyone knows only too well, kills.
So who knows how many people we're killing? (I use the industry "we" here).
We should all make sure our systems are designed to a high professional standard. Why should Software engineers be the only engineers allowed to do a bad job? Engineering is a precise profession. It can apply to us just as well as the guys who build jumbo jets.
Cheers,
Karim.
|
|
|
|
|
I don't disagree with your points at all. I enjoy doing detailed specifications. I actually think I am better at the design stuff than the actual programming side of things.
All I'm trying to say is that the time required to do justice for the design of a sufficiently large application is simply prohibitive for a small shop. A small shop trying to produce even a relatively modest business type application will go backrupt following your advice.
To succeed, you have got to get an actual application out the door. Buggy or not, customers will flock to the first app that generally satisfies a basic set of defined needs. And they will stay loyal to that product as long as the bug fixes come in a timely fashion. I've seen it happen too many times. Again, I'm not saying it is a good thing. I'm just saying it is reality for a significant portion of this industry. And, in truth, it is the customers own fault that it happens.
We should do everything humanly possible to produce bug free code. But a hard core QA session at the end of a defined development phase will be much more effective at that than taking the time to write up detailed specs. Aspects of the design that just don't work can be removed, or designated a feature. (I have also seen that happen more than once - what we thought was a design flaw turing out to be an important customer's favorite feature. Go figure.)
"Thank you, thank you very much" Elvis.
|
|
|
|
|
I chose 1 and I hope anyone can explain to me why they would choose anything but 1*
Remember we are talking commerical here. Not our home/hobby projects were it is agreeably way more fun to just dive into the coding.
* 2, maybe, if the job was pressured or you did not have an analyst handy
regards,
Paul Watson
Bluegrass
Cape Town, South Africa
"The greatest thing you will ever learn is to love, and be loved in return" - Moulin Rouge
Martin Marvinski wrote:
Unfortunatly Deep Throat isn't my cup of tea
Do you Sonork? I do! 100.9903 Stormfront
|
|
|
|
|
Paul Watson wrote:
chose 1 and I hope anyone can explain to me why they would choose anything but 1*
A lot depends on the quality of the specification you receive from the "customer". It's very hard to design something totally when you only receive half a spec from the "customer". It's usually in-house applications that suffer from this, where there isn't a formalized procedure for making changes to software. I tend to work on a component basis, design a component, code the component, move onto the next component. By the time all the components are finished, you just pray and hope that the spec is complete so that you can design how the components interact with each other.
Paul Watson wrote:
Not our home/hobby projects were it is agreeably way more fun to just dive into the coding.
Yes, but that does tend to mean bring bad habits over to "commerical projects" too.
Michael 
|
|
|
|
|
Indeed.
On my IT-school, we even learn to do it this way. So, maybe THAT can add some extra power to it. And on the office I work, we do it also this way.
|
|
|
|
|
Michael P Butler wrote:
A lot depends on the quality of the specification you receive from the "customer".
You get your customer to write the spec? Hmmm. The way we do it is this.
1. Customer tenders for project, or calls us (or we call them.)
2. We write a sales proposal and they accept it. This is done with a bit of consultation with the client. In it we define the broad scope of the proposed solution.
3. I go in and start analysing and designing the solution. I go onsite, talk to the client, look at their current systems, talk to people in the office. This goes on for about a week or so.
4. I start pulling together all my notes and ideas, putting them into a functional spec which defines down to the last page and button what the solution does and how it works.
5. We then cost the project (hopefully not too far off the initial sales proposal) and then the developers and I sit down and start planning the whole thing.
We plan each component but also how each component fits into the bigger puzzle.
Overall we spend a good few weeks, if not a month or two, speccing and planning the project. Then we go into coding.
Michael P Butler wrote:
Yes, but that does tend to mean bring bad habits over to "commerical projects" too.
True. It is a hard habit to break.
regards,
Paul Watson
Bluegrass
Cape Town, South Africa
"The greatest thing you will ever learn is to love, and be loved in return" - Moulin Rouge
Martin Marvinski wrote:
Unfortunatly Deep Throat isn't my cup of tea
Do you Sonork? I do! 100.9903 Stormfront
|
|
|
|
|
Then half way through the developement he signs a change order that screws up half of the design.
Tim Smith
Descartes Systems Sciences, Inc.
|
|
|
|
|
Tim Smith wrote:
Then half way through the developement he signs a change order that screws up half of the design.
That is why our Specification document (before planning) is a signed contract with all our clients. Planning and development do not proceed without their sign off saying that the solution we produce is what is written in the spec.
If they do change their mind though half way through we re-cost the changes and it's impact on what we have already done. We then present them with that extra costing and then they sign that off. The project timeline is also changed of course. All of this is signed and agreed to by legally binding contracts.
At the end of the day while it is frustrating to have changes half way through a project we ultimatley like it in monetary terms as we normally increase our hourly-rates for mid-project changes. If the client does not like it then we tell them to wait until the project is finished, and signed off, and then do their changes in a "Phase 2" project.
We are very strict, anally so, about all this because in the long run it is best for the client and us. After a successful project the client normall agrees and has a good laugh at all the changes they wanted half way through a project and are glad it is in phase 2 rather.
regards,
Paul Watson
Bluegrass
Cape Town, South Africa
"The greatest thing you will ever learn is to love, and be loved in return" - Moulin Rouge
Martin Marvinski wrote:
Unfortunatly Deep Throat isn't my cup of tea
Do you Sonork? I do! 100.9903 Stormfront
|
|
|
|
|
Yup, exactly how it should be.
As much as I would like to say you are wrong, up front spec is the best solution when it can be applied (which is all the time if they allow you to do up front research.)
Tim Smith
Descartes Systems Sciences, Inc.
|
|
|
|
|
Tim Smith wrote:
As much as I would like to say you are wrong
Errrr umm, thanks, I think... 
regards,
Paul Watson
Bluegrass
Cape Town, South Africa
"The greatest thing you will ever learn is to love, and be loved in return" - Moulin Rouge
Martin Marvinski wrote:
Unfortunatly Deep Throat isn't my cup of tea
Do you Sonork? I do! 100.9903 Stormfront
|
|
|
|
|
Paul Watson wrote:
I chose 1 and I hope anyone can explain to me why they would choose anything but 1*
Most of the time it's not the choice of the developer but rather a dumb management (I think it's called "increased producvity").
Since the pool title is "How much design and planning do you do?" and not "How much design and planning do you/would you choose to do?" I am forced to choose other options, even thought personally I would opt for no 1 as well.
Paul Watson wrote:
Remember we are talking commerical here. Not our home/hobby projects were it is agreeably way more fun to just dive into the coding.
I think it's the commercial side that suffers on the design part more than "hobby projects" (home projects, being often a testing ground for technology don't require as much design since you will dive into unknown and want to be flexible).
|
|
|
|
|
George wrote:
Since the pool title is "How much design and planning do you do?" and not "How much design and planning do you/would you choose to do?" I am forced to choose other options, even thought personally I would opt for no 1 as well.
Well luckily we do, do 1 where I work.
regards,
Paul Watson
Bluegrass
Cape Town, South Africa
"The greatest thing you will ever learn is to love, and be loved in return" - Moulin Rouge
Martin Marvinski wrote:
Unfortunatly Deep Throat isn't my cup of tea
Do you Sonork? I do! 100.9903 Stormfront
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
