August 31, 2015 at 9:41 pm
Comments posted to this topic are about the item Software Estimates
September 1, 2015 at 3:06 am
The trouble with being a developer and estimates is that estimates tend to be wrong. As a developer I do not want to be wrong.
I want to get it right, first time and every time.
That plus most managers often taking an estimate and hew the date/time in stone makes a developer more than reluctant.
Learning when it is ok to fail is a wonderful experience for developers. Especially on something easy like estimates.
It does not hurt to get better in estimation and it is a skill like every other one. Experience and practice will hone it.
And to do about managers? Either a list of 25 points of pre-requisites attached to the estimate (most will never read it) or some sort of blunt instrument in reach will help with 99% of all the "But you said...".
September 1, 2015 at 3:29 am
Typically the construction industry is much better at estimates. Its when the client turns around and doesn't want the ground surveys done correctly that predictably everything goes wrong. Or the client changes their mind Sydney Opera House being one of the classics. Yes there are unforeseen issues but the construction industry tends to cope with them better.
Both the construction industry and software development have many issues in common: uniqueness of each new design, modular techniques, etc. Although designing a new IT system doesn't shouldn't really get delayed by bad weather.
In IT we often don't do enough prep work and our modular design seems to be a bit too un-modular at times. We also suffer from people wanting to argue against the obvious facts. Never heard anyone wanting to argue with a thousand tonnes of concrete or say the forces of gravity wont affect an RSJ.
September 1, 2015 at 5:49 am
I think changing scope and situations occur in every industry and the entire reason we are paid is because as professionals we deal with it.
When you are billing time and materials like lawyers or doctors, or the rare software project then scope change this is not a problem.
However, when you have a fixed price / fixed deadline project it can become a problem where conversations have to be had and sacrifices have to be made in order to remain profitable and still deliver the greatest value. The estimation problems may have occurred during bidding, when we knew the least about the project.
I think the problems with estimation typically revolve around not asking enough of the right questions. This is where experience comes into play.
If you find that you are not estimating very well do a quick debrief or 360 project reflection on what could have helped make a better estimate. Create yourself a checklist, or at the very least approach new estimates with a risk assessment mindset on what is everything that would have to go right for the project to be successful and what are the most likely things that could go wrong.
I once heard someone say that a fixed price project is like eating at White Castle and every couple years it sounds like a good idea, but you regret it the next day.
September 1, 2015 at 6:09 am
Mt project plans require an end date. Hard to do this with piecemeal implementations.
September 1, 2015 at 6:16 am
I'm not really seeing the connection between the first linked stories in the first paragraph.
A solution--which is what the doctor is aiming to apply--is totally different than the benefit from the solution, which is the process of feeling better.
The doctor should know some pretty good exacts on how long it takes to do surgery, to apply a shot and so forth. This is because the doctor has done this a million times before and the results are almost always the same. When I say results, I'm not referring to the benefit of feeling better, but the results of the solution being applied.
The feeling better though, could differ from patient-to-patient. As you may here from cancer treatments, not every case is the same. Everyone is different and thus customized treatments are needed. The knowledge of those treatments in regards to time and resources is pretty exact. The reaction from the patient is not so exact.
That being said.
Using the above examples. If you do something long enough that includes the same approaches, then you can get better at estimating time and resources. If the solution is unpredictable, many changing variables and so forth, then yes, it's going to be difficult to do those estimates.
But, you can't compare those to exact solutions that never change. As a developer, I try to fit people into exacts to help better understand estimates.
September 1, 2015 at 7:27 am
The idea of telling a computer to do x seems more bounded and contained than other professions, but it's really not. This is often because developers don't get a complete statement of all the requirements from clients. However this also isn't really any different than many professions. How many of you know exactly how you want a house built, or legal matter settled, or the specifics of medical treatments and effects?
Hi Steve,
What makes software and database estimating so difficult, even more so than legal defense or medical procedures, is that the client is telling us not only the outcome they want but to an extent how to do it. The client driven requirements actually add to the complexity of the project.
For example, a defendent doesn't tell an attorney how go about building his defense (generally speaking), and a patient doesn't tell a physician how many stitches they expect to see after the surgery. The outcomes in the area of legal defense and medicine are standardized.
However, computer coding is more like gourmet cooking or movie production where the client is sitting up front in the passenger seat and dictating turn by turn adjustments along the way.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
September 1, 2015 at 7:41 am
I think a part of the problem with software estimating versus the construction industry is that in construction, the customer can physically see the progress that's been made. If, for example, the basement is build and there's a framed house on it, the customer can see that it would be hard to add 200 square feet in one direction with basement below it. Not so with software. The customer may be able to see a site taking shape, but they can't relate to all the work necessary for a change similar to the house example.
The scope creep can also be a real problem. When I have a deadline, the changes need to stop before the deadline arrives in order to have any chance of getting the project done on time. I live in a world where changes are still coming even after the deadline has passed and I'm being asked why we didn't make the deadline...by the same people! :w00t:
I know there are cartoon panes on this all over the place, but I've used a construction example in describing why deadlines are missed sometimes. The original spec called for an outhouse. The customer really wanted a house. The first change was to add an elevator. With all the changes that crept in along the way, what was delivered resembled the Tah Mahal and had first strike capability and it's own satellite. What was quoted? Who knows, but it was probably over budget. 😛
September 1, 2015 at 7:55 am
Estimating an IT development project help if you start with a framework. For example, in the home construction industry, unless you're going for a multi-million dollar Frank Lloyd Wright style design, even the so called "custom built homes" are really based on a limited selection of standard cookie cutter plans that the builder presents to the customer up front. The customized part is just the customer choosing which style of hard wood floors, appliances, and counter tops which accounts for maybe 10% of the effort and cost of the project.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
September 1, 2015 at 8:43 am
I'm a firm believer in the Scotty Principle of giving estimates. Or as I explained it to someone I used to work with, if something will take an hour, tell whoever asked for it that it'll be done in 4 then deliver it in 2.
September 1, 2015 at 9:28 am
The doctor who gave the prognosis of 1-2 months for my Mom was correct.
It is a very interesting subject. Has anyone collected data as well as anecdotes?
412-977-3526 call/text
September 1, 2015 at 10:50 am
I've read before some interesting articles about a concept called the "cone of uncertainty". Essentially estimating too precise too early leads to poor estimation. Software projects tend to have complex or changing requirements over time, even if that project is only a month long. One place I worked at had an easy early estimation process simply asked if I thought something was going to take hours, days, or weeks to accomplish. A more precise estimate could be given later once we got into more details.
There's also the effect of trying to measure things in mythical uninterrupted work hours. People in IT tend to be pulled multiple directions at once, and can be frequently interrupted. This affects if you're measuring things in work hours or elapsed time.
And the last point I'd like to add is the complexity of the tools and environment we're working in. I've told people before that my job is about half trying to get the technology to do what it's supposed to do, and half trying to figure out what people want it to do.
September 1, 2015 at 10:55 am
xsevensinzx (9/1/2015)
I'm not really seeing the connection between the first linked stories in the first paragraph.A solution--which is what the doctor is aiming to apply--is totally different than the benefit from the solution, which is the process of feeling better.
Maybe, but there are lots of medical issues where the doctors don't know. They try one thing and then another. Especially when you have joint issues, skin fungi, and plenty of other issues.
Don't compare a shot to building software. A shot is like setting up SQL Server or IIS. I can tell you how long that will take. The process of diagnosis and therapy often is open ended, with doctors being unsure of outcomes.
I just went through something like this with a friend. A broken bone in a finger, and the estimates by the doctor of healing time and treatment were off by over a factor of 100%.
September 1, 2015 at 10:55 am
Joel Ewald (9/1/2015)
I think changing scope and situations occur in every industry and the entire reason we are paid is because as professionals we deal with it.When you are billing time and materials like lawyers or doctors, or the rare software project then scope change this is not a problem.
Yes, very true. We need to deal with it. I think we also need to set better expectations, as well as perform better.
We do ask lots of questions. The problem is the answers aren't often known, or revealed.
September 1, 2015 at 10:58 am
Eric M Russell (9/1/2015)
Hi Steve,What makes software and database estimating so difficult, even more so than legal defense or medical procedures, is that the client is telling us not only the outcome they want but to an extent how to do it. The client driven requirements actually add to the complexity of the project.
For example, a defendent doesn't tell an attorney how go about building his defense (generally speaking), and a patient doesn't tell a physician how many stitches they expect to see after the surgery. The outcomes in the area of legal defense and medicine are standardized.
However, computer coding is more like gourmet cooking or movie production where the client is sitting up front in the passenger seat and dictating turn by turn adjustments along the way.
I'll say my experience is different. I've rarely been told how to build software. I might get suggestions, but certainly defendants, patients, and even customers of craftsman have all sorts of "suggestions" on how to do things differently.
Maybe there's a wider variety of outcomes in software, but I'm not sure. Legal issues, outside of win/lose, are often very murky. Decisions are made in unexpected ways all the time, based on the way defenses are presented. Same with many medical protocols. There's a bit of an art with many professions.
Viewing 15 posts - 1 through 15 (of 29 total)
You must be logged in to reply to this topic. Login to reply