Software Best Practices

 

My copy of Facts & Fallacies was delivered over the weekend and I read the introduction, the 1st couple of facts and then skimmed the conclusions.   In the introduction, Glass explains that the facts were chosen because they’re fundamental to software engineering and are frequently forgotten and not used.

 

He explains that there’re no solutions in the book, although, some references may describe solutions.  The fact is explained, controversies are explored and then he lists references. 

 

So I wade in and start reading the first facts concerning Management.  The 1^st fact is that the quality of the programmer is the most important factor in software development.  This is a well known fact that I had heard before. 

 

As I read I think back on my recent experience as a database practice lead and say to myself, “yes. But how do you identify the good programmers?”   

 

I know that we wrote development best practice guidelines for developers and advocated that they use them in code reviews.   I need to know what code is and what good designs are before I can say anything about the quality of the product or the people who wrote it.  In addition, once developers review each other’s code and think about best practices then the best programmers will come out.  The best presenters aren’t always the best programmers. 

 

I turn the page and see that the 2^nd fact is related to the first.  The best programmers are 28 times better than the worst programmers.  Two paragraphs down Glass states that the SE industry doesn’t know how to identify the “best” people.  I’m thrilled to see I’m thinking along the same lines.  Maybe I’ve had a good education after all.

 

So I skip to the conclusion.  Glass provides more insight into the purpose of the book that’s not in the introduction.  In a nutshell, very bright people are adopting technologies and methods in ways that aren’t supported by these well known facts.  They’re advocating fallacious proposals.

 

A light flickers in my brain as I wonder that perhaps Glass has created a set of best practices that practitioners can use to review, evaluate and adopt sound technologies and methods that make sound business and engineering sense.  They’re a good fit for their intended purpose.

 

I’ll read the rest of the book with this in mind.

 

Nice start. I still have to crack open mine but a question came up as I read your post. Can you be a great programmer in one situation and only a moderate programmer in another? Is it something to do with the fit of programmer to the problem?

Oh absolutely. 

Anytime programmer's are transitioning onto a project they usually start out as moderate until they understand the problem to be solved and the system itself.  Learning new languages is another case of a great programmer slowed by the learning curve.  These are often underestimated. 

To get more to heart of your question though the complexity of modern systems almost guarantees that a programmer will not be great over the entire system.  That's not just because the tools are specialized but the design paradigms are different too.  For example, when software is offered as a service over the web it requires different technologies to deliver the whole solution, from asp.net to c# to sql server.

The design paradigms range from UI and usability to OO and SOA to data modeling.  Extremely few programmers would be considered great at all layers of the tech. stack.  They simlpy can't put in the time at each layer to be great.

What business drivers will influence the choice to use generalists or specialists?  One question I'm interested in is how do we recognize good designers?

 

talmans,

The question of "how to recognize good designers" has been asked before. In Glass' "Software Creativity 2.0" book, he writes about a study done by a guy named John Nestor (then at the SEI). Nestor's "Great Designers" study entailed him identifying who he thought were the top 10 designers based on his experiences working with them. He then interviewed each of those 10 people asking (among other things), "What makes great designers?". There were some interesting conclusions from analyzing the interviewee's responses. All great designers seem to have:

    *) A large set of standard patterns--in other words, many previously-solved approaches to problems

    *) They've lived through failed projects, but more importantly they had learned from those failures

    *) They had mastery of the their tools

    *) They had little fear of complexity (ed: "in the problem space")

    *) They had a strong preference for simplicity (ed: "in the solution space")

    *) They were good at anticipating change

    *) They had an ability to appreciate the user's perspective

This also reminds me of a paper written by Bill Curtis. I'm pretty sure the title of the paper was "Managing the Real Leverage". Bill set out to correlate observable factors about developers (e.g., years of experience, school, job title, etc.) with productivity (as measured by how long it took to identify and repair defects in a non-trivial section of code). Long story short, none of the factors except one had any correlation whatsoever with productivity. It didn't matter what school you went to, nor how much you were paid, nor how long you'd been employed. The only thing that seemed to matter was the number of different *programming paradigms* that one knew. By paradigms, I mean something like OO vs. Lisp. Smalltalk, Java, C++, and C# are all in the same paradigm (procedural OO) so they don't count. But Lisp vs. Prolog counts because they are fundamentally different approaches to solving problems.

Bill's proposal was that by knowing more solution paradigms, one had more ways to think about problems and think about solutions. The more productive person would simply solve the problem in the most appropriate paradigm and then map that solution over into the actual language paradigm at hand. It makes a lot of sense to me...

So maybe the above is the beginnings of a list of criteria to use in finding the really good designers that are out there.

 

Cheers,

-- steve

 

1. The most important factor in software work is not the tool and techniques used by the programmers, but rather the quality of the programmers themselves

 

2. The best programmers are up to 28 times better than the worst programmers, according to “individual differences” research. Given that their pay is never commensurate, they are the biggest bargains in the software field

3. Adding people to a late project makes it later

This is mostly true. Pfeffer and Sutton claim in their book Hard Facts, Dangerous Half Truths and Total Nonsense that great people is not enough. It has been a bit since I read the book but the idea is that crappy process will drive out good people. Moderate process and moderate people actually outperform good people in a crappy process.

 

In a way, fact 1 sets up a false dichotomy. It is not about choosing one or the other. It is probably way truer that good people and good process is way more powerful than good people regardless of the process.

 

I think that the real lesson to take from fact 1 & 2 is that you can’t treat the people like cogs in a machine. I really have not run into any company that does that. I keep hearing rumors of corporate leadership trying to get purely fungible people but have not seen it in practice. Yet I think that many line people believe that the leadership wants fungible resources. I wonder where the truth lies there.

It is interesting that it Glass quotes my boss as the loyal opposition. I don’t think McConnell would agree (I will have to corner him and ask him). McConnell position is more of using careful planning rather than throwing resources at a problem. Further, McConnell recently shared with me some data from Putnam & Myers' book Five Core Metrics that the sweet spot for a team is 5-7 people. Meyers & Putnam found that for a given project size, increasing the team size to over 9 people increased the length of the project and the amount of effort. Adding people over the sweet spot actually increased effort on a project.

 

I think that a more interesting point is that when a business person or a manager asks a question like, “How many people do you need to get this done by X”, that almost always it is already too late. Not that adding people will make it later but that there is almost no way to get those resources on-board and up to speed in time to aid the project that is already under some sort of schedule pressure. Finding people, especially good people who can help meet an already aggressive schedule, is usually not an option.

4. The working environment has a profound impact on productivity and product quality.

This entirely depends on the kind of thinking you want to do. If you want to do individual thinking, then the need for a quite, undisturbed place is required to get into the flow state. However, if you plan to do thinking in a collaborative fashion (compensate for the lack of flow state by the unblocking properties of multiple heads) then you want a more communication oriented environment.

 

What we see is that the best of breed environments have a mix of quite and collaborative (caves & common model) appropriate to the type of thinking that needs to happen at different parts of the project.

 

This, I agree, is counter to the facility managers who count cost per square meter of floor space. I know one company who issues Bose noise cancelling headphones to each new developer to try to get the mix. Laptops and hoteling are also common solutions. However, it is up to the development shop’s leadership to make a business case for the cost of effort and how much cost avoidance (I never say savings anymore) we can achieve by the proper environment.

My article "Brooks Law Repealed" is often misunderstood. My point is that most people unintentionally misapply Brooks' Law. The law is not "adding people to a project makes it later." The law is "adding people to a late project makes it later." Brooks' point is that in the project "end game" (i.e., very close to the end of a project) adding new staff will distract existing staff to such a degree that you lose more productivity than you gain. If you're not in the end game, however, Brooks Law doesn't apply. The distraction still occurs, just like it does during a project end game; the difference is that if you're not in the end game you will have enough time for the new person to ramp up and to make a net positive productivity contribution before the project ends, even accounting for the distraction of the existing staff. I think Glass, Brooks, and I all agree on that.

The point of my "Brooks Law Repealed" article was that people grossly underestimate their projects and then they track them ineffectively. So they think their projects are smaller and shorter than they are, due to underestimation. And they don't know how far they really are from being done, because of ineffective tracking. They then invoke Brooks' law saying, "We're almost done, so we can't add people." But, they're not really almost done. They only think they are. The resulting pattern is all too familiar: Project teams invoke Brooks Law and say, "We can't add staff to the project because we're only 4 weeks from delivery." 6 months later, when they finally do deliver, it's clear in hindsight that they had plenty of time to add staff and for those staff to make a net positive contribution during the remainder of the project.

 My conclusion is that Brooks Law is not a good first order approximation. The best first order approximation -- for use by projects that don't do a fantastic job of estimating or tracking -- is to go ahead and add staff if you think you need to, because you're probably not as close to being done as you think you are. If you are doing a great job of estimation and tracking (and you know who you are if you're one of the rare groups that is doing that) then you'll be sophisticated enough that you don't need to rely on a "first order approximation" like Brooks Law; you can actually make a more substantive decision based on the facts of your particular situation.

Steve,

That's a good list, and thanks for including other writing on the topic.  Knowing different paradigms hadn't occurred to me.  I don't have a broad range of paradigms but it makes sense.  I've developed client/server information systems for many years and have experience in data and procedural oo paradigms. It's interesting though, a few of Joe Celko's books focus on this. He compares solutions based on graph theory vs. those based on set theory.

At a recent company a big topic in engineering concerned adopting a dominant design paradigm, oo or data models or neither.  I don't know that any one should be dominant across the board.  Each component or layer will have a dominant paradigm but each could have a different one. This is a case where it depends on the tools and languages to be used and the engineers who use them.  Part of choosing the right paradigm is explaining it in a way to make it simpler to build and maintain.  

Even within similar languages, C# and Java for instance, there are subtle paradigm differences.  Fowler discusses this in Patterns of Enterprise Architecture.  C# is based more on record sets than Java so the implementations can be subtly different as well.  I've seen Java developers struggle with this when working in C#.  The same solutions don't always scale as well when ported to the other language.

I think about what I'd ask in an interview.   I usually scale the solution up and ask what would happen to different aspects of the system when variables change. Mostly questions with no right answer, (I ask them better than I answer them).

I’ve seen junior developers reason these out better than more experienced developers. Now, I’m curious.  I’m going to ask about their backround.

 

Regards,

Talman

 

 

Earl,

You make a good point about, facts 1 and 2, in not discounting a good process and focusing totally on good people.  This got me thinking about the agile movement.  I think the agile movement really embraced the focus on people in facts 1 and 2. Although, it’s ironic that many agile processes are more prescriptive about what engineers should do and how to do it than other processes. 

This is to all our benefit because it got the industry focusing on specific best practices for building quality into products and project planning & tracking in a way that hadn’t been done before.   Even though the many ideas are have been around for awhile the industry finally embraced them and some are quite innovative.

I don’t know that corporate leaders want purely fungible people. They do want people cross trained to minimize the impact of people leaving.  I’ve worked in some very small growing companies where they didn’t have the resources to adopt all the people first practices.  Office space and training is expensive.  Business owners sacrifice these things for themselves when they start a business and this frugalness is a necessity and a virtue to growing the business.  I don’t think this view totally goes away and this is reflected in the budgets.  I don’t know when a business would transition to spending more on people but clearly that’s done often too.

Enjoy the game.

Talman

 

Steve,

Your list of criteria has even wider application.

Steve Tockey:

All great designers seem to have:

    *) A large set of standard patterns--in other words, many previously-solved approaches to problems

    *) They've lived through failed projects, but more importantly they had learned from those failures

    *) They had mastery of the their tools

    *) They had little fear of complexity (ed: "in the problem space")

    *) They had a strong preference for simplicity (ed: "in the solution space")

    *) They were good at anticipating change

    *) They had an ability to appreciate the user's perspective

As you know, the Chaos study lists Experienced Project Managers as the #3 critical sucess factor. Your list is also the beginnings of criteria to use in finding the really good project managers that are out there -- or maybe I should just say really good <fill in the discipline>.

Regards,

Jerry

 

Earl,

That’s a good distinction.  I’ve worked in several teams that benefited from sitting close together in an arrangement to facilitate communication. I’ve also been in quiet office space and been productive there too. I agree with this fact but I’ll play devil’s advocate.

I’ve worked in some small growing companies where they didn’t have the resources to adopt all the people first practices.  Office space and training is expensive.  Business owners sacrifice these things for themselves when they start a business and this frugalness is a necessity and a virtue to growing the business. 

I don’t think this view totally goes away and this is reflected in the budgets.  I don’t know when a business would transition to spending more on people.

If a professional is dedicated and committed to the company then office conditions will have little impact. The wimpy geeks need to buck up and not let office conditions stop them from succeeding.

Talman

Hype is the plague on the house of software. 

Most software tool and technique improvements account for about 5 to 35 percent increase in productivity and quality.

But at one time or another, most of those same improvements have been claimed by someone to have "order of magnitude" benefits. 

This is one of the central themes of the book. Awareness of these facts & fallacies enables one to think critically about the latest doodad and make a sound business decision. Three observations come to mind.

-          Decision making in academia and industry is different.

-          Software is still more craft than engineering.

-          The industry is driven mostly by vendor products.

Academia likes logical arguments and high levels of certainty and industry likes to take risks and make gut decisions. I don’t think business leaders are actually expecting orders of magnitude improvement. They’d be thrilled with 30%.  However, quite often new technologies are hastily used, and even applied inappropriately, so they don’t even realize a 5% improvement.

It’s also indicative of software development as a craft instead of an engineering discipline.  I know several large software companies petitioned my state’s education system to create a curriculum to better train software engineers. I read the report.  However, these corporations don’t even insist that the new degrees are added to job descriptions.  Quality engineers are trained but the knowledge isn’t leveraged.

Vendors build what industry asks them to build, new features.  The languages and computing environment get more complex yet the development tools can hardly keep pace.  I’ve always believed that once the requirements and design are well understood then the implementation is relatively trivial. Yet tools for requirements and design are still cumbersome to use and not integrated into the development environment.

I think part of the problem is that the development tools and languages aren’t all that good and change very often.  Engineers have their hands full learning how the latest language works, sometimes coding around its bugs.  Industry responds by making more wizards that generate verbose, bad code, if they let you see it at all anymore.  In this way engineers can’t focus on the bigger problems and ask for appropiate tools.  This loop is one reason why requirements and design tools get little attention.

Granted, these are the harder problems to solve and harder tools to write. This is a good lead into Fact 6. 

Regards,

Talman 

I see this very close to fact six as well. I like to call it the Hype-Disillusionment Curve. It is not the distance between the Now and the Hype, it is the distance between the loss of productivity (fact six) and the hype that kills so many good ideas that may have some benefit. Can it be that turning fuzzy requirements into software is a fundamentally hard problem that NONE of the tools attack head on? Instead of helping developers to read minds and customers to truly understand their unstated needs, our tools help turn poor requirements into solutions sooner. I don't think it is hardware envy either. I think the complexity of software has grown faster than "power" of hardware. That is, the way the software interacts and the multitudes of problems it designed to solve are increasing a huge rate. Software engineers are, in a way, their own worst enemy. As we figure out how to solve one problem, that just make the clients want even more (if you can do that...). We buy the hype because we want to solve those more complex problems as efficiently as we solved the previous less complex problems. However, the more the complexity rises, the less efficient we become. So, we look to anything that says it has a handle on that.

Learning a new tool or technique actually lowers programmer productivity and product quality initially. The eventual benefit is achieved only after this learning curve is overcome. Therefor, it is worth adopting new tools and techniques , but only (a) if their value is seen realistically and (b) if patience is used in measuring benefits.

See my post on fact 5 about the Hype-Disillusionment Curve. The distance between the trough of disillusion and the push of the hype is usually quite a ways. It is here that the less savvy organization looks at the "so called" improvement and declares it a disaster. Instead of riding the curve back up, they abandon the improvement and try something else, riding down the next trough of disillusion. While Glass identifies that the interesting question is "How Long". How long does one stay in the trough before (a) you should give up or (b) you start to climb out. One rule of thumb that I have heard is three cycles of use. Anyone else hear that?