Software Best Practices

I've always been advised to never say "no". Saying what can be achieved or how many resources a project would take is the better answer. 

 Reuse-in-the-small, (libraries & subroutines), began nearly 50 years ago and is a well soved problem.

This is true and may be instrumental in the software productivity gains over the last 15 years.  The IDE environments include large libraries and tool boxes of basic routines.   

Reuse in-the-large, (components), remains a mostly unsolved problem, even though everyone agrees it is important and desirable. 

 Reuse in the large works best in families of related systems and thus is domain independent.  This narrows the applicability of reuse in the large.

There are two rules of three in reuse;

a) It's three times as difficult to build reuasable components as single use components.

b) a reusable component should be tried out in three different applications before it'll be sufficiently general to accept in a reuse library. 

Modification of reused code is particulalry error prone. If more than 20 to 25 percent of a component is to be reused then it's more effective and efficient to rewrite it from scratch.

Design pattern resue is one solution to the problems inherent in code reuse. 

For every 25 percent increase in problem complexity, there is  a 100% increase in the complexity of the solution. That's not a condition to try to change. That's just the way it is.

Eighty percent of software work is intellectual. A fair amount of it is creative. Little of it is clerical. 

The pressures on each are totally different. I remember when I first moved into management, it was all about "what are you going to do to get your team to meet x". It sort of stopped being about the right answer and more about motivating and plotting. It really sucks you in.

The answer here may lie more in the establishment of common goals. Many projects operate without any explicitly stated goals or something pretty useless such as "meet the requirements". That makes it really had for the larger team to come to any kind of consensus.

I guess there is a difference between "NO, you bloody idiot! What part of "impossible" don't you understand?" and "The was it is currently defined has an extremely low probability of occurring. Let's look at some options."

I think the killer point here is that a feasibility study usually involves technology feasibility. To the technology people, it is a challenge and, for that reason alone, worth promoting. Steve Tockey's book, Return on Software make the case that software should be a business proposition. I have seen few (gosh, if any) feasibility studies come back with financial data. Mostly, they just state if the technology is cool or not.

Have to agree with this. Reuse always starts out with huge aspirations and then it turns into something small but useful.

I have had the pleasure of watching several generations of this. The issue is that in the large, we are not all trying to solve the same exact problem. The take on a problem changes from organization to organization and even among individuals.

For me, I have given up getting excited over reuse. I don't recommend it to my customers because those that want to follow it are already doing so. Those that may benefit from things like product lines are usually so have process so far removed from being able to take advantage of it that I might as well say use anti-gravity pods.

That's a great distinction. Once we know what it takes to make it happen technically then we need to decide if it makes business sense to do it.  These are in business plans, marketing studies and gutsy hunches.

I wish I'd have seen this too.   I was deeply involved in building and maintaining a Software As Service product.  I think this is another solution for reuse in-the-large, albeit indirectly.

I proposed a reuse approach to our problems but had the same response as you.  The business focus was on growth not optimization and the process maturity reflected that too.  It's a cultural change and a technical change.

 Reuse in-the-small is more of an engineering department activity.  Reuse in-the-large requires change and support from the whole company.

This is true because because business requirements and design decisions are also reused but only if you plan for it. 

The impetus of a product line approach was to reuse requirements and software for similar software products.  By parameterizing the actual code base a company could support a family of related products from one cheaper to maintain and verify code base.

I think Software As Service, SaS, models can be viewed as a family of products.

SaS systems are a collection of components or entire applications that are configured to deliver the required behavior for the customer.  The product can be defined as the differing feature sets that customers buy and use.  Engineering's job is maintaining the core code that provides the capability of delivering products from the family. However, if the product is considered one big configurable application maybe it isn't a product line.

I decide by looking at the business model. If a large requirements effort is required to deploy a customer's solution and new functionality is added to the product for some customers it could be more efficient to think of delivering a family of products.  This will also optimize the requirements, design and test phases of the lifecycle.

Cheers

Coincincidently, after building 3 similar products it's beneficial to adopt a product line.  

Rules of three are pretty common. It often takes three cycles to learn a development tool as well. I think Bob Glass had a re-usability issue since he spent so much time on it. I really don't see re-usability as a big issue for our clients. They all would like it but more if reusable components just appeared.

WooHoo, we are off re-usability!

I think this is one that needs to be put on the walls of any marketing or sales group. One of the phrases I feared the most coming from a marketing person was the introductory clause, "It is just a..." because of this fact. Many thought adding one thing here or one thing there really didn't make that big of difference. But, as Glass says, the complexity of the solution, not just the design but all the work that needs to create the solution, goes up at a much higher rate.

Probably so. It's so complex its extremely tough to verify. I think if any code is modified by more than 20% it should be rewritten or refactored so its unrecognizable. 

Really though this is a code quality issue.  If the changes don't break many module interfaces a rewrite wouldn't be needed. If it isn't well designed acording to the prinicples of information hiding a rewrite is the best solution.

I couldn't agree more. And the first engineer that agrees to that ".. one little thing..." without thinking it through should be tacked to the wall right next to it.   This is the central fact of the book, according to Glass.  The downstream effects of small changes are so hard to foresee but we know there'll be something.

It explains the interest and difficulty with adopting useful code reuse. The difficulty in reviews and testing.  The fact that languages and tools change so fast they keep our eyes focusing on learning tools instead of practicing design adds to the problem.  Productivity goes up but not simpler solutions. 

We all see the effort to manage this in software companies yet the cost of building internal tools to help manage it is rarely worth it.

This fact supports Glass' argument that software automation, CASE tools and MDA, isn't currently feasible.   There's not a lot of supporting evidence but I believe it too.

The single hardest thing to do is decide precisely what to build.  This would have to be done up front to automate the construction of a program. This could be done iteratively but formal methods would be needed to specify the requirements.   

The first 22 of the 55 facts are about management in chapter 1. Almost half the book!  Clearly good software management, like in anything, is important to success.

Several key areas were covered, People, Tools, Estimation, Reuse and Complexity. The SDLC wasn't covered but that's in chapter 2, followed by quality in chapter 3.

Some of my takeaways.

People are the most important factor in software success.  There're huge productivity differences between engineers.  Management needs to recognize good engineers, make their engineers better, use them wisely and be able to recognize good work when they see it.

One of the two most common causes of a runaway project is fact 8, poor estimation.  The other is the first fact in chapter 2, unstable requirements.

The central fact of the chapter, 21, defines software complexity. There's a fourfold increase in complexity from problem definition, requirements, to the end solution and delivery. There're usually enormous downstream impacts from the seemingly simple changes in requirements.  Making it more difficult is that there's a disconnect between those making requirements decisions and those developing the solution.

A good read although some facts seemed a little arcane but this was on purpose.  A few times Glass pulled back from refuting conventional wisdom because he didn't want to offend his coleagues.  It would have been better if he had taken that challenge and addressed the issues. 

It's a good read.