|
You mean there are projects where the requirements don't keep expanding on a monthly basis. I have 2 people with the goal post strapped to them and they are running in opposite directions.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Even if the code fairies come in and do the work over-night (and they often do), their efforts will always be thrown off track by the capriciousness of the project-management unicorns.
Nothing, apart from bad news, moves quite as rapidly as the goalposts in a software project.
Whenever you find yourself on the side of the majority, it is time to pause and reflect. - Mark Twain
|
|
|
|
|
|
Ill be finished if only "they" give me fully articulated requirements, and agreed upon by all share holders, else there can be no deadline.
|
|
|
|
|
Software delivery can be boiled down to a simple mathematical formula;
time-to-delivery = (sales * bullshit) + (management * incompetence) - (programmer * overtime);
Everyone has a photographic memory; some just don't have film. Steven Wright
|
|
|
|
|
I had a sales guy tell me (The Programming Manger):
Product - Sales = SH!T
He wrote it loud and proud on the whiteboard, letting me know that his job was more important than mine.
I laughed... And I said. While it is possible to sell a product that doesn't exist, I can't be expected to deliver it... Furthermore:
Selling + Never Delivering = Fraud
So, how about we work together...
And believe it or not, we both ended up working pretty well together. He always thought the tech people were just cry babies about change... He didn't realize it literally took days and weeks to do things that were EASY TO SAY. LOL...
|
|
|
|
|
I had a sales/manager/electrical engineer for a boss one time and he would always ask for a bid on work then at a later date come in and say "I've got good new and bad, good news we got the job bad news we have to do it in half the time". Turns out that's the way they made most of there money by overruns.
Everyone has a photographic memory; some just don't have film. Steven Wright
|
|
|
|
|
Kirk 10389821 wrote: e didn't realize it literally took days and weeks to do things that were EASY TO SAY.
Software development is like procreation - 6 minutes of fun and 9 months of gestation, most of which is often quite uncomfortable 
|
|
|
|
|
Mike Hankey wrote: time-to-delivery = (sales * bullshit) + (management * incompetence) - (programmer * overtime);
I think you forgot a few ^ in the bullshit, incompetence and overtime.
|
|
|
|
|
Marc Clifton wrote: incompetence
Implied 
Everyone has a photographic memory; some just don't have film. Steven Wright
|
|
|
|
|
Stating what we all know: At best, delivery dates are an estimate and finished is undefinable as requirements always change during development.
Concepts like Continuous Delivery is merely a response to management's Continuous Harassment and Incompetence (CHI is a real thing too!  )
|
|
|
|
|
+1. Yes, there are times when there's a meaningful due date. Some regulatory agency requires changes in reporting by, say, April 15.
For most development, though, dates are arbitrary. Stupid people add stress to their development cycles by setting arbitrary restrictions on development. Less stupid people work diligently, and release when "done enough". As Marc says, continuous development/delivery.
Of course, "done enough" is sometimes tough to determine. We, as geeks, need to realize that we're in a business environment, and stop solving the problem at some point. We're generally not great at that (ooh, it would be even better if I added this one little tweak, a small abstraction here...).
|
|
|
|
|
agolddog wrote: Of course, "done enough" is sometimes tough to determine.
Nah. When boredom meter hits a certain threshold, it's "done enough."
|
|
|
|
|
We don't need no stinkin' Deadlines!
Since I don't count the ubiquitous ASAP as a deadline - and if one uses there head, that's when everything is done by definition. The main obstacle to timely delivery is that the user (or their proscribed minions) don't put in the time to testing/approving their requested item, even though they were in such a rush for it . . . does this sound familiar to anyone?
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
If you study a newspaper (that is, physical paper) presenting several stories on one large page, look at the last sentence of each story: If you chop it off, you don't loose much of the story. Even the last paragraph can be chopped off. Maybe two paragraphs. Maybe even more, all the way up to the headline.
A newsstory writer organizes every story he delivers to the desk with the essential elements in the headline, the important stuff in the ingress, and the text body content becomes gradually less significant (and more repetitive) as you get towards the end. As a reader, you will never see the end of the story: All stories come to the desk with a lot of filling that is chopped off so that the remaining fits into the page, together with the other stories.
In software development, it is not the "size" of the new features that must fit into the type bed (i.e. development time frame), but the importance. If you complete the most important new features first, complete and tested, ready for release long before the time, then spend your resources on the second most important feature, and so on, at any given deadline date you release whatever has been completed and tested. You leave out the rest of the features, even if they are completed - but not tested. What goes out at deadline is what is fully completed and tested.
This is the basic idea behind Continous Delivery, but many software companies don't use CD that way: They continuously put together a dozen of half-completed features, none of them functionally complete, none of them thoroughly tested. They treat it as if every single line of code written that day must be included in the nightly release build. No! The nightly release build should not include a single line that is not ready for final release! Only the fully complete modules.
CD may of course reveal that integration of a new module didn't go as smoothly as hoped for; there was a conflict with some module completed earlier. So the next morning you do not have a new nightly release. But the one from yesterday can be delivered to the customer (of course it won't have that new feature that couldn't be integrated, but the essential extensions are included).
For this philosopy, the ideal would be to put all available resources into one feature at a time, completing them in order of importance. Obviously, setting two hundred developers to implement a single feature is not possible (or efficient use of resources). Lots of them will have nothing to contribute to the nightly release until later. Yet, enough resouces should be allocated to complete every high importance feature ('complete' in the sense: Fully tested and ready for release) at half time, at the very latest. Or to rephrase it: Set the release date twice as far from the start date as the (realistically) estimated time to complete the must-have-features. If the must-have-features takes more than twice as long, then the estimates were not realistic, and you deserve angry customers because you are delayed...
Like a newspaper editor chopping off the tails of the news stories, leaving ony the essential parts in the page, the project leader must chop off the new features, leaving only the essential new features in the release.
|
|
|
|
|
In the real world, importance of features is ultimately subordinate to dependencies. Now, if you're in a manger-driven fantasy world where the pretense of progress is displayed by continuous deliverables, you can make up an absurd scenario that numerous potentially disjoint features can be made in some order of priority - and patch in the connectivity as best you can down the line.
Being overly harsh:
Ass
Grasping
Idiots
Louse-up
Everything
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
I can say I have had luck, but I would prefer to think I am good at what I do.
I mean, there have been deadlines that were not accomplish but due to changes in specifications by the customer, mechanical problems, components delivery...
But so far I was never the cause of a delay in any of my projects.
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.
|
|
|
|
|
We release when the number of completed features asymptotically approaches the marketing curve within a reasonable their exhaustion distance, and the slope of the new Closed-Loop Corrective Actions (CLCA, yeah it's a thing) per week is below the need for revenue recognition.
In other words, it ain't never finished.
Software Zen: delete this;
|
|
|
|
|
When we just need to solve the problem at hand we always release on time. The trick is to ignore 90% of what the customer says he wants, and just focus on a profitable solution for all parties involved.
Customers are always happy when they end up saving a quantifiable amount of time and money in the end.
Sometimes, during complex joint-efforts, we'll start adding random user-requests at the end of a cycle to stall for time while the other involved parties get their act together.
This has happened on all joint-efforts so far, because every damn time there are a few engineers involved that over-design everything. 
It's annoying when people redesign something to avoid having to actually build it.
|
|
|
|
|
But ... you have to explain the delay to the customer, and give him a reasonable delivery date. And meet it!
Sent from my Amstrad PC 1640
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
If a software developer told me that he wouldn't deliver until the code was 100% free of bugs, I'd go to another developer to get something that I could use while waiting for that 100% bug free code. I wouldn't be too afraid of having to pay both of them
I think most "Hello World!" programs are 100% free of bugs. I can't think of any useful software the same way.
|
|
|
|
|
I think that says a lot more about your code than it does about mine!
I'm not saying my code is bug free, but there are no known bugs in the code I do release. Releasing code that you know doesn't work properly is an anathema to me, just as releasing a car when you know the brakes will fail if you use them going downhill would be to a car manufacturer.
Sent from my Amstrad PC 1640
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
