10x Software Development - All Comments

re: Software's Classic Mistakes--2008

ravinder — Thu, 05 Jun 2008 10:23:01 GMT

thank you for nice post

re: Software's Classic Mistakes--2008

daviddaly — Wed, 04 Jun 2008 21:55:04 GMT

Thanks for another great post!

It is difficult to know why the same mistakes continue to be made. Possible theories that I have include:

Long learning cycles – because many software projects are long few people experience enough of them in their career to learn all the required lessons.

Blaming other people – all too often people, teams and companies blame someone or something else for project failure, an attitude that hinders learning and improvement.

Post rationalisation – no matter how badly a project goes people look back and think “we did the best we could” which again prevents them from learning effective lessons

A lack of time for reflection – it is only possible to learn from mistakes if you take the time to properly reflect on and evaluate how a project went.

I have gone into a little more detail on my blog post about this at outofthetriangle.wordpress.com/.../do-we-learn-from-our-mistakes

re: Software's Classic Mistakes--2008

ravinder — Thu, 29 May 2008 07:26:59 GMT

thank you for nice post

re: Software's Classic Mistakes--2008

Anonymous — Fri, 23 May 2008 14:19:29 GMT

I've passed along other articles by Steve to the rest of my department - often getting spirited debate ("Technical Debt" was highly regarded).

"Software's Classic Mistakes - 2008" was met with silence. I had to check with a co-worker to make sure the email actually made it through. I think we've got some elephants in the room that nobody wants to talk about.

Astonishing.

re: Software's Classic Mistakes--2008

Ali Kitabi — Fri, 23 May 2008 05:45:22 GMT

Thanks for sharing the information.

I think that most of the risks indicated can be handled at while working in a software firm, however when working in a corporate sector you are cramped up by the upper management pressure who are not so savvy about the software development risks. You always have less time therefore you need to balance out your variables from Product/Quality/Cost. Of which most of the time quality has to stand aside.

re: Software's Classic Mistakes--2008

Andy — Thu, 22 May 2008 15:50:28 GMT

I think a combination of the invisible nature of software, and the idea that software development is an art, not engineering. If the focus was on engineering, learning best practices, and educating the workforce on topics like estimation, project management and SDLC, would be more common. It still seems to be isolated, companies doing/learning all on their own. You don't see construction companies figuring out how to build buildings or bridges on their own. Which ties into Maksym's comment, when learning on your own, its hard to figure out how to avoid classic mistakes.

re: Software's Classic Mistakes--2008

Abhi — Sun, 18 May 2008 18:05:34 GMT

As a project manager, I never abandon planning because I realize that the project plan created at the outset is only the best case scenario plan and it may need to be changed at any given moment.

re: Software's Classic Mistakes--2008

Maksym Shostak — Sat, 17 May 2008 20:42:49 GMT

Maybe, people keep making these mistakes because they don't know about them. If they do know, they don't know recipes to avoid the mistakes.

Are there classic recommendations to eliminate these issues?

re: Software's Classic Mistakes--2008

Steve McConnell — Thu, 15 May 2008 15:31:48 GMT

John, The reason "noisy crowded offices" came out higher than "abanding planning" is that it was found to be more common. As the summary table says, abandoning planning is more serious when it occurs--it just doesn't occur as often.

re: Software's Classic Mistakes--2008

John Rutter — Thu, 15 May 2008 12:19:24 GMT

Interesting figures, but I wonder about the ranking if 'noisy, overcrowded offices' came out above 'abandoning planning under pressure'.

Maybe there are some office conditions out there that are *really bad* :-o

re: Software's Classic Mistakes--2008

Mark — Thu, 15 May 2008 01:27:54 GMT

If I have to hear one more person tell me that they're really good at multi-tasking and that they're "just as productive doing more than one thing at once"... or worse... "that they get more done that way", I'm going to lose it.

Meanwhile, the dates just keep sliding on by.

re: Software's Classic Mistakes--2008

Paul — Wed, 14 May 2008 18:53:38 GMT

Thanks for sharing the classics!

Estimating is a professional skill. Developing it requires training, good coaching & practice. There's no substitute for experience, performance data & lessons learned. In addition, the ability to communicate to management (& other stakeholders) in their language is essential.

If you're a technology expert, amateur estimator, no historical data & lessons learned to support you -- and don't know how to tell your story in others language -- you'll need a lot of luck and a very forgiving manager.

re: Software's Classic Mistakes--2008

Jan — Wed, 14 May 2008 10:32:28 GMT

I think a lot of problems stem from the invisible nature of software. Nothing can measure the progress of software except usage; unlike a building which gets bigger or a bridge which gets longer.

Since most software progress information is a proxy for the real thing it has far greater error baked into it. And yet it's treated with the same levels of confidence as progress of physical construction.

re: Software's Classic Mistakes--2008

Luis — Wed, 14 May 2008 02:59:32 GMT

Thanks for making this information public. Why do people keep making these mistakes? It would take a Ph.D. in Psychology to really answer this. However, I have one theory. We all have a risk threshold we're willing to tolerate. In some cases, we will actually add risk to a low risk situation in order to reach that threshold. For example, studies have shown that people who, by law, must wear seat belts (i.e. lower their risk), will drive a little faster, a little more aggressively, etc. until they reach their personal level of risk comfort.

I think this natural human characteristic comes into play when people manage software projects. In addition, I think there is a fundamental lack of education in basic topics like estimation, project management and even client management.

re: Measuring Productivity of Individual Programmers

Solidpoint — Thu, 08 May 2008 09:16:03 GMT

I like the comments of Chris Mountford the best. The only measure of productivity is how much did it cost to deliver the functionality the user wanted - or should have wanted - as is too often the case. A real-life example illustrates this well. When I worked at Citicorp another R&D group spent several million dollars rewriting an ALCO related program to give it a GUI because the users were inputing data in a big, unstructured file and would make input errors like double decimal points, resulting in the failure of a 12 hour job. The GUI, predictably, was very tedious to use and output the very same flat file users had been creating in Notepad for years. Users hated the GUI. They wanted to copy a large file, modify a few things, and know it wouldn't blow up somewhere in the night due to data entry errors. I wrote a recursive routine to check common data entry errors, support embedded comments, and sent it to a friend who was doing damage control on the GUI project. My 3-4 hours coding replaced, and surpassed several million dollars worth of development as the users quickly abandoned using the GUI entirely after a stand-alone validation utility was made available. I could also point to a small CASE system I wrote and used to generate 12 billion lines of prototype code at FIB bank in the 80's...and on and on. Software is congealed intellect. If you don't know the domain you're working in don't be surprise if MOST of what you produce turns out to be redundant. Remember this when some guy is sitting staring at his screen for hours, scribbling on a white board, or is taking long walks with the other super-nerd in your group. It may well be that he's found a way to meet your goal 10,000 times faster. Are you smart enough, and do you know the domain well enough to know when he's bringing you a moon-rock? That is the challenge. Great software isn't a process of saving money, its a process of implementing inspired genius - in exactly the same way that the CFO can never save his company to greatness. Engineering can. Marketing can. The leasing department can. The bean counters can't. Their role is defensive. The best they can do is contribute at the margins by making the process of implementing genius cheaper - right up to the point where they kill it entirely.

re: Productivity Variations Among Software Developers and Teams: The Origin of "10x"

AmazingMo — Thu, 24 Apr 2008 03:16:36 GMT

Joel Spolsky makes a corollary to this point in his blog post "Hitting the High Notes". Joel focusses on the difference between programmers who can solve hard problems, and those who can't, but he also has some data that supports the 10:1 case along the way. If you've read down to this point, you probably will want to look for Joel's post too.

Cheers.

re: Measuring Productivity of Individual Programmers

Mal — Wed, 23 Apr 2008 21:52:32 GMT

Don't take this the wrong way Steve, bu can I have your baby?

Every time, I read one of your books or blogs I walk away incredibly impressed.

re: Measuring Productivity of Individual Programmers

Mitch Barnett — Mon, 21 Apr 2008 22:38:46 GMT

All good stuff, but here is a real world problem, I and others face all of the time. I work for a professional services company and we build large scale, custom ecommerce sites. Customers want us to estimate the effort and therefore cost and schedule to deliver the project on with nothing more than a features list.

As odd as it may sound, each ecommerce site is quite different in functionality (not necessarily content) and in most cases, we may build from the ground up, but it is built on top of an ecommerce framework. Still it may take 60K lines of custom code on top of the framework to implement a project.

So what are the best ways to estimate the effort? Tried FPA, but that requires skills beyond what we have. We have tried other levels of abstractions like use case estimating and the like, but not with a great deal of success. It seems like the only way is back to counting lines of code.

We can equate lines of code to features, which is how the ecommerce project is sold. For example, a PayPal payment feature may be 50 SLOC’s Are there any tools that can help us build a features library and then store historically both the lines of code and the effort it took to write those lines of code, so that over time we can just assemble the estimate from this library?

Would be very curious to hear other options or opinions… Many thanks in advance?

PS. I wish we are at a level that we could worry about programmer productivity, we are still at the stone age level of just trying to grasp the size and effort of our projects…

re: Measuring Productivity of Individual Programmers

Chris Mountford — Sun, 20 Apr 2008 12:08:15 GMT

Why do you hire a programmer? So that your LOC graphs go up?

A good productivity indicator correlates strongly with real business value.

If you cannot measure productivity - and for simplicity's sake I'll assume that degrades into an inability to measure value, then maybe there is no value there! What makes you think there is value? You know there is value and you know you should be able to measure it but why is it so hard?

Perhaps because you're trying to measure some abstract intermediate indicator of progress (such as lines of code). Failing to find a satisfying (reliable, consistent) abstract intermediate indicator of progress does not imply that developer productivity cannot be measured.

My preferred measure of programmer productivity is based on passing tests on shippable software. What kind of tests? All the kinds you need to show your software does what it is supposed to. Tests not enough for you? Where is the problem now?

re: Measuring Productivity of Individual Programmers

chrishmorris — Fri, 18 Apr 2008 19:22:44 GMT

A measure of program size that I like is the number of assertions in an adequate set of test cases.

re: Measuring Productivity of Individual Programmers

Gabriel Belingueres — Fri, 18 Apr 2008 14:54:06 GMT

I would measure productivity of an employee based on the common sense: There are no unproductive people in a project if there are no stressful situations regarding the people in the office.

So I would measure as how many stressful situations are present in the working office because of this employee's work/decisions/behavior.

This of course has sense if you can trace back the problem to the right time and person. For software developers you can see who committed a file in a source repository. Other tools may help but traceability is the king here.

In every project there are little failures and successes so this would be the rules for assigning a "productivity index" to person P:

a) If P's decisions/work (which are OUT of the scope of P) lead to a past/present/future non stressful situation for at least other person in the project, then he has +1 point.

b) If P's decisions/work (which are IN the scope of P) leads to a past/present/future stressful situation for at least other person in the project, then he has -1 point.

c) When the manager is in doubt, run an ANONYMOUS survey asking the team WHO's work/decision leaded to the current stressful situation, and WHY. (Include yourself in the survey.) If 80% of the answers conclude in the same guilty person AND reason then you assign a -1 to this person.

At the end of the period (month/year/etc) sum all the points of each employee and then you have it.

Gabriel

re: Measuring Productivity of Individual Programmers

software_engineer — Fri, 18 Apr 2008 08:35:59 GMT

good post ..

all of us know that measurement is a tricky thing and it influence productivity very much .. every article like that it is very usefull to read ..

thank you.

re: Productivity Variations Among Software Developers and Teams: The Origin of "10x"

Guillermo Schwarz — Tue, 15 Apr 2008 20:06:34 GMT

About the 10% of programmers who couldn't complete the assignment, a few years ago I interviewed 100+ Java developers.

I asked them to reverse a String.

Half of them couldn't complete the assignment and 80% of that half didn't even try.

The test has 24 questions. Only one developer replied 22 correctly but we couldn't afford him. The second best answered 18 correctly and was affordable.

The developer with the lowest ranking that was hired only had 5 correct answers of 24, and the project was a huge success.

Management was totally surprised by the high level of productivity (measured in use cases per month), by the quality of the product and the incredible team motivation.

All we did was to hire the best our money could buy, give them powerful machines, compile automatedly with ant, run unit tests with junit, and functional tests with selenium.

There were other tricks like doing prototypes and converting them into libraries, reducing code duplication, having written and updated code conventions, doing a code review before any check-in, having a team leader in each layer, etc., but having the best people was clearly our most important asset.

re: Productivity Variations Among Software Developers and Teams: The Origin of "10x"

riya — Tue, 15 Apr 2008 02:04:18 GMT

how do we calculate the productivity pf a programmer x who has done module 1 p lines in 2 days and module 2 k lines in 3 days

re: Measuring Productivity of Individual Programmers

Ben Northrop — Mon, 14 Apr 2008 21:09:48 GMT

Excellent post! I think an interesting angle to consider is how developing for maintainability and reuse can affect productivity over time. A developer who solves a problem rather myopically, not considering future requirements/changes, might look like a super-star initially in terms of productivity - he finished his feature on time, wrote a lot of function points, had no bugs, etc. Three months later, however, when a new round of requirements comes in, his productivity may plummet (or at least stagnate), because his prior work didn't make his future work any easier. A good developer knows when to sacrifice productivity in the short-run to realize gains in the long-run, however a manager who uses single, one-point-in-time metrics of productivity might actually discourage developers from writing clean/reusable code - which will of course hurt productivity in the long run.