|
I found it interesting that the 'leader'/ in this poll is interpreting specs or lack thereof.
I see software developers as being the ones responsible for producing those specs in the first place - I thought the days of the coder were long gone, but it seems I'm wrong.
Although in my current job we do have Business Analysts whose specific job it to produce a spec on which all parties agree, it's been a long time since I've worked ion an 'in-tray' environment - these days it is a collaboration, where we all ensure the specs exist and are understood - and when they change during development, to make sure we all agree on those changes and understand the new desired results.
We do have those here that seem to think that their job is just to type in code and have someone else provide a spec and test it for them, but I thought that was unusual - is it not?
PooperPig - Coming Soon
|
|
|
|
|
Explaining my boss and/or our customer that his vision won't play out in reality (only if that's the case of course) as well as he think it will (or usually it won't at all). Even though he's really, really positive it will. Even though it didn't in the past. Even though he explains it many times over. Even though he's the boss (or customer), you know! It just won't. Period. Reality is like that. Yet... we're usually forced to do it anyway. 
|
|
|
|
|
Damn, writing code is difficult! 
THESE PEOPLE REALLY BOTHER ME!! How can they know what you should do without knowing what you want done?!?!
-- C++ FQA Lite
|
|
|
|
|
Beat me to it, my answer was "All of the above".
Simon Lee Shugar (Software Developer)
www.simonshugar.co.uk
"If something goes by a false name, would it mean that thing is fake? False by nature?" By Gilbert Durandil
|
|
|
|
|
I agree... 
Nirav Prabtani
|
|
|
|
|
If you have proper sprint planning, then it forces better user stories, so lack of documentation goes out the window. Testing, and more testing.
|
|
|
|
|
It seems you're busy on those. Long time no see
|
|
|
|
|
Yeah, I decided to take a break for a while...lost focus. Work has been extremely busy, in a good way. Good to see a lot of the old-timers are still active on the site; including you.
|
|
|
|
|
Even I'm not that much active. For last 3-4 months I was mostly in reading mode. I have noticed that bunch of old timers inactive. Surprisingly Pompeyboy is more active than average lounge regular guy on recent period.
|
|
|
|
|
Quote: "The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time."[1]
—Tom Cargill, Bell Labs
My another favourite:
Quote: Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law.
— Douglas Hofstadter, Gödel, Escher, Bach: An Eternal Golden Braid
|
|
|
|
|
The one I know is similar to your first quote:
2% of the time to make 98% of the work. 98% of the time to correctly finish the other 2% of the work.
(I don't know who told it)
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
|
It is the most muddy topic. I thing the natural human language is not suitable to create the short and self-constistent requirements.
|
|
|
|
|
We build commercial ink-jet printing systems, so for us it's testing.
When we do have a machine to test on, there is a set schedule for each group to get test time on it. I've worked on special versions of products for customers where we didn't even see the hardware until it was time to deliver the machine. We've had engineering prototypes for new products sold out from underneath us.
"It's a madhouse I tell you! A madhouse!"
Software Zen: delete this;
|
|
|
|
|
Gary Wheeler wrote: I've worked on special versions of products for customers where we didn't even
see the hardware until it was time to deliver the machine.
It happened to me as well in past. Only option was Trial and error[^] which was really a terrible time consuming process & BORING one 
|
|
|
|
|
In one case, I was sent to a customer site in England for ten days to test a special modification we'd made for them. It was supposed to work in conjunction with some additional equipment from another manufacturer, which we'd never seen and had only receive a single specification from.
I spent the ten days standing around while the other manufacturer tried to get their *cough* prototype *cough* working.
Software Zen: delete this;
|
|
|
|
|
Even I spent a day or two to a client place couple of times for printers. Got issues like drivers failed or invalid version. It was thermal printer. we tested our code with one printer which was given by printer guys. But later we found some other printer which didn't work properly, we got print with improper format which was really useless.
Most terrible thing is Client called us for printer related issues. One time my collegue told me that they called him to solve an issue. But he found that they didn't on the printer. After that, we usually told clients to print a test page to redirect them to printer guys.
After these things I hated to work on hardware things like printer, barcode scanner/printer, etc.,
|
|
|
|
|
Gary Wheeler wrote: I've worked on special versions of products for customers where we didn't even see the hardware until it was time to deliver the machine.
Pfft! Try programming conveyors that can't be completely programmed until they are built and once they are built the client thinks they should be able to immediately use them because they are built.
Lots and lots of 36 hours days during that phase of my career.
Psychosis at 10
Film at 11
Those who do not remember the past, are doomed to repeat it.
Those who do not remember the past, cannot build upon it.
|
|
|
|
|
As an occassional app developer for both Android and iOS the nightmare is always having to grapple with the kafkaesque labyrinth that is Apple's publication process. Even if I simply want to deploy an app directly to our own fleet of iPads it is completely obscure. The Android situation is better but not much.
It is probably fine if you are frequently doing mobile app projects and tageting the mass market so want your stuff to appear in the App Stores, but for in-house custom development it is awful.
RogerCO
|
|
|
|
|
Most product managers are clueless and their specs are full of gaping illogical usability holes! Asking dev to add features which makes no sense to the customers.
|
|
|
|
|
I found the most hardest bit is the specifications provided by the client, which is always volatile. This happens in more than 95% of the cases. In worse scenario, it happens unpredictably and changes the whole stuff finished so far.
However, I guess this is the nature.
|
|
|
|
|
Swinkaran wrote: I found the most hardest bit is the specifications provided by the client
My experience has been the specs provided by the salesperson. They always leave off features they promised the client but failed to make any record of what they promised.
I had one time we were working long hours to complete the code for this conveyor and three weeks into the project and at the end of a 24 hour day the plant manager starts talking about this feature he's looking forward to that my programming buddy and myself are wondering what drugs he was on (or wondering if we needed to be on some) to later find this major portion of the specs was completely missing and the deadline was a week away on what we estimated was going to be a two week effort to add the missing feature. We didn't even have the hardware to implement the feature, let alone program.
That was just one of many "Oops" by sales.
But yes, we had some where the client asked for something that had no chance of working the way they thought it would.
Psychosis at 10
Film at 11
Those who do not remember the past, are doomed to repeat it.
Those who do not remember the past, cannot build upon it.
|
|
|
|
|
the missing option is EVERYTHING.
App development is a pain compared to desktop... or even server.
|
|
|
|
|
What about desktop apps?
Software Zen: delete this;
|
|
|
|
|
Desktop apps are ease provided you're not trying to make them with a "blahML" (HTML, XAML, etc) interface. It's been several years now, and every interface design program I've dealt with for desktop, nothing comes even remotely close to the ease and speed of simple WinForms in Visual Studio. Drag, position, rename, tweak a handful of properties, done.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
