Software Best Practices

Glass leverages Fact 6 on this one. Because developers don't work through the learning curve of new tools they don't see the productivity gains and quick using the tool.  Often this is because so many projects are schedule driven and its common for people in a stressful situation to revert back to what they know.

This basicaly resulted in the shelfware phenonmenon of the 80's and 90's and we only now are coming out of it.  The latest IDE's have integrated more tools, like source control, unit test and continuos intergration, so tool adoption does happen.

Design tools and requirements still aren't integrated into the development tools.  I know database case tools are very useful but they don't integrate well with standard source control systems and as a result don't mesh well other developers. There's always a disconnect between these groups.

Glass makes the point that a minimum standard tool set for software development has never been defined.  What should the minimum standard toolset be?

What is it in your company? 

 

The next several facts are about estimation so I'm posting them all at once.  I'd be interested to hear the many different ways these facts have been overcome in industry.  Anyone reading  this can chime in. No one has to read the book to participate in this thread.

 

One of the two most common causes of runaway projects is poor estimation. 

 

 

Most software estimates are performed at the beginning of the life cycle.  This makes sense until we realize that estimates are obtained before the requirements are defined and thus before the problem is understood.  estimation, therefore, usually occurs at the wrong time.

Most software estimates are made either by upper management or by marketing, not by the people who will build the software or their managers.  Estimation is, therefore, done by the wrong people.

 

 

Software estimates are rarely adjusted as the project proceeds.  This those estimates done at the wrong time by the wrong people are usually not corrected.

 

 

Since estimates are so faulty, there is little reason to be concerned when software projects do not meet estimated targets.  But everyone is concerned anyway.

 

There is a disconnect between management and their programmers.

In one research study of a project that failed to meet its estimates and was seen by its management as a failure, the technical participants saw it as the most successful project they had ever worked on.

 

This one is only partly correct. Estimates MUST be made at the beginning. This idea that we have to wait until we are half done before an estimates is totally nuts. We must make business decisions much before that.

What is different about early estimates is that early estimates have a different precision and more uncertainty than late estimates. For example, an early estimate may be (for a one year project) something like 3 to 7 quarters. Imprecise numbers with a wide range of uncertainty. Is this useful? Well, if you budgeted for only 2 quarters worth of work, it is darn useful.

The answer is that we need many estimates. As we progress through the software, estimates become more precise and the confidence increases.

 

This is so true. I think that tasks to refine estimates and the product delivery date isn't built into the plan. Many times corrective action isn't taken until its too late and a major rescoping effort takes place late in the project.  The first response is to try to pull the project in instead of resetting expectations.  This is an area where the disconnect between management and engineers widens.

The agile methods of time boxing feature enhancements and shipping when the product is ready is an innovative attempt to address the difficulty with this. Even so the customers and others need some lead time and expectations set early to know when the product will be released. There's a lot of planning required before a product can be shipped and used.

 

 

I'd agree with that, especially on large projects you do need estimates at the start. What I think also happens is that what you estimate changes - you start with a big problem and an estimate with a large degree of uncertainty and then as you progress you break it into smaller bits and estimate each of those with a higher degree of accuracy.  If your still estimating big things - even later on, your estimates are still going to be pretty inaccurate. Just because you might know more about the problem doesn't necessarily make it any easier. Also if your estimating smaller things and get a few of them wrong it MAY have less of an overall effect...

 Finding big things later on is a sign of missing requirements or not understanding the size and complexity of certain features.

Don't you think that "missing" is kind of a strong word? I think some of it is down right "unknowable" at the start. To say you missed it suggests that is knowable and we didn't do a good job.

 Unknowable is a better choice of words.  Although, this gets to the nitty grittys of when do you have enough requirements to move on. 

The sdlc choice has an impact too. An iterative approach to uncover requirements mitigates the risk of requirements changes downstream.  I suspect that the inital estimate range would be quite large if many changes were expected.

Another aspect of this is that often management and the customer hear the earliest date in the estimate range, while engineers are building to the middle or last estimate of the range.  The heart of the matter could be that management is actually asking for a commitment too early and is uncomfortable with a wide estimate range.  

The negotiation of scope and features happens at the wrong time.  Initially the scope is too big and is trimmed as a last resort, too late. 

This is where technologists can help by managing up.

I think the agile approaches directly address this issue by redefining how projects are tracked and when they're ready to ship and, therefor, the definition of a successful project.

 

I've experienced this one.  Senior engineering managers have said that they expect managers to be able to estimate for their engineers. Once they get a sense of their velocity they can begin to make estimates.  Product target delivery dates need to be driven by upper management.  This is a reasonable business expectation.

I wonder though that the difference between commitments and estimates gets in the way.  "Software Estimation" by Steve McConnel explains this very well. This is a good book.

If management sets delivery targets that are consistent with accurate estimate ranges and the estimates were adjusted as the project progressed it'd work great.  

Often the early estimates are taken for committed delivery dates.  Once committed dates are set noone wants to move them.  Often they try to add slack in the target date to accomodate changes in the project as it progresses.

 

This is basically true too. Although, I wonder again if this really refers to the committed date or the estimate. I guess practically spekaing most projects only have the one estimated/committed date and they're the same thing.

The project committed dates are usually adjusted very late in the project as a last resort.  

Sometimes though I've been asked for an estimated delivery date and responded that I'll get back to them with mored details.  I then come back with a range of dates and many assumptions and questions to be sorted out.  The usual response is a request to commit to providing a committed date.  When can you provide a narrow highly accurate estimate?

Once these dates are communicated to the customers and sales people noone wants to change them.  These are business decisions as much as engineering decisions.

 

Sure everyone is concerned when commitments to the customers and rest of the company aren't met.  Everyone wants to improve and make this easier. 

Sometimes

I think this is one of the great messages from the agile community. The "business" only gets to decide value. "Development" get to define the cost (estimate) the work. This is a better level of division than the "business" deciding the value and the cost.

However, we development people need to give the business a respectable estimation process so that they can trust the cost. I know when I get estimates on other work in my life, it is considered good practice to get a least two (think home projects, car repair, airline tickets, etc.).

I think you are right. The issue is that a true estimate is more of an analysis of the work than a prediction of delivery. As an analysis of the work, it make common sense to re-do the estimate as we know more about the work.

When we confuse an estimate with a target. The target can be just about anything and probably should not change. The target reflects the values of the business and to change it suggests confusion on the business' part. What can change is the commitment that is the intersection of the estimate and the target.

Final note, I think that there are there three areas to estimate: schedule, cost, and functionality. The commitment, that which will be stable, can only exits on one (maybe 1.5) of those. There must be some flexibility in at least one of the three to meet the commitment.

Yes. I had a VP of Engineering once that liked to say, "The business decides what's needed and Engineering says what it can deliver and when."  Engineering would estimate, scope and define the phased releases to deliver the functionality.  The CEO at the time agreed with this approach. The VP also challanged our estimates too.

We'd work with marketing, of course, on the requirements and project scoping.  Unfortunately, marketing wanted to decide when the requirements are complete, the scope, target window and even the amount of effort spent on quality.    So it was a challenge.

I like the idea that developers need to provide a respectable and trusted estimation process.  This is so important for a business.  That requires a learning curve and several honest tries and a willingness to adapt to get good at too.  To me this is an engineer's viewpoint.  The whole business has to buy into it too.  

 Cheers,

Talman 

 Absolutely and usually resources (people and budgets), the costs, are fixed.  Occassionaly consultants are added to the team.  That leaves schedule and functionality.  The management teams need something to adjust and negotiate otherwise they can't really manage the project.

One of the challenges and areas engineers can get better at is understanding the size and complexity of the work to be done.  Getting an accurate and fine grained breakdown of tasks is a bit of an art too.   

Talmn 

I was mulling this over yesterday and it occurred to me that while this is true it doesn't make sense that it should be true.  Manager's used to be technical and have experienced the disconnect first hand yet once in management they do the same thing.

This one might be more of a management social science fact and outside the scope of software engineering.

Managers promote technologists that are fine with the status quo and make it work.  Once promoted they continue the same approach because that's what their managers and the rest of the company expects.  It's what they know and change is risky and tough.

It's interesting how cultures persist even the people change.

Developer's and engineers need to understand the business environment and its strengths and weaknesses and recommend appropriate actions. They manage up.

I could see how technologists would see it as successful if they're happy with the product and their effort. Other things are outside their control.