The Artima Developer Community
Sponsored Link

Weblogs Forum
The Second Time Around

7 replies on 1 page. Most recent reply: Jul 18, 2003 12:34 PM by Carl Hartwick

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 7 replies on 1 page
B. Scott Andersen

Posts: 16
Nickname: bsandersen
Registered: Jun, 2003

The Second Time Around (View in Weblogs)
Posted: Jul 6, 2003 11:39 AM
Reply to this message Reply
Small companies struggle to get their first product out the door. That's probably no surprise. But, the next hurdle may be even more difficult: getting the second product, the next generation product, out the door. The problems are not necessarily technical -- but they can be deadly for a young company nonetheless.
"If you don't create the replacement for your current product, your competition will do it for you."
-- Accepted product wisdom

The Second Time Around

Small companies struggle to get their first product out the door. That's probably no surprise. But, the next hurdle may be even more difficult: getting the second product, the next generation product, out the door. The problems are not necessarily technical -- but they can be deadly for a young company nonetheless.

I believe part of software engineering is the management of risk: risk assessment and risk abatement. There are risks associated with second generation projects in start-ups and small companies that are not present in first projects. These new risks are often a result of organizational changes made since the first product's development. In order to manage a risk, you must first understand it. It also helps to have a name for it.

In the book AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis the authors discuss things done wrong over and over. Providing a name for a pattern of idiocy can be useful. I'd like to borrow the term "antipattern" for this installment of my blog to highlight three particular kinds of idiocy associated with second generation project development and the risks that they bring. They are:

  • Waiting too long to start,
  • Ancestor worship, and
  • Elitism and Jealousy

There are probably many more but these three should provide a good starting point for discussions.

Waiting Too Long to Start

R&D costs, especially in technology companies, can be a daunting, up-front expense. Once "out of that phase", the company's management is measured on their ability to get the company to profitability. This means, of course, increasing revenue and, most likely, reducing expenses.

Technology products typically have a limited useful life in the marketplace. Their lifetime varies, depending on what kind of technology we're discussing. A particular model of computer hardware may have a useful lifetime in the marketplace of 12 months. A particular version of software may have a lifetime of 18 months. A video game might have a useful lifetime of 4 to 6 months. Devices and software outside of the consumer channel last longer. It is this type of market, where the product churn is slower, where I believe most problems occur.

In the early 1990's I worked for a small company that made restaurant management systems. They had a product that they had sold for years... many more years than its useful market life. They could see that the sales of their existing product were falling. Yet, for a very long time, they did nothing. Finally, they hired a fellow to lead a team create a new product to replace their old product. I was hired into the team later.

The first problem encountered by the new product team was discussed in an earlier blog: no product management leadership. Everybody knew that the old product was no longer viable and that a new product was necessary if the company was to survive. Unfortunately, nobody could agree on what form this new product should take. What if you made a decision or expressed an opinion and it was wrong? Now that revenue was dropping precipitously on the old product, the new product had to be a success. Nobody wanted to be blamed for its failure.

There was a concern that the new product wouldn't sell. Note how this is different from the typical mood around a first product of a start-up! The prevailing notion there is, "if we can just get it built, we'll get rich." There is rarely the fear that "nobody is going to buy this pig."

There was also a sense of betrayal among the staff that had worked in product support for years. The original product had become quite familiar to them. It was a comfortable relationship. Now, there was going to be this new product, new problems, and new technology with which they were untrained. For a time, they would need to support two products: the old product and the new one. There was a sense of resentment that their world would be turned up-side-down. That sentiment was probably universal throughout the company.

As money began getting tight, the pressure to ship the new product was intense. Finally, with the company on the edge of bankruptcy, the product was shipped -- at least 6 months before it was really ready. It was a disaster.

Then things made a turn for the worse. The cadre from Marketing and Sales now descended into Engineering blaming the developers for the poor quality and unhappy customers. The software was buggy and unreliable. It was also unfinished (a point we made repeatedly and fell on deaf ears at the time). Instead of working with Engineering to develop a plan to get the software finished, however, the Marketing and Sales forces leaned on Engineering for more features. Presumably, these were the features that the latest round of sales prospects mentioned.

I'm sure you've heard this at some point: "If we don't have this feature, we can't make the sale." If Engineering refuses, Sales tells management they couldn't close the deal because of Engineering's recalcitrance. If Engineering tries to put in the feature and it doesn't work right (and how could it?), then Marketing and Sales tell management that they can't sell a product that is so buggy.

At some point, one of the Marketing bozos came to talk to me directly. I was just an engineer at the time. (I would later run the department after my manager's departure.) Like each of the many days before, he had some feature he wanted built immediately. I pointed out that the checks printed by the restaurant system weren't always right and that the accounting system for the restaurant itself didn't always balance. Didn't he want us to fix those things first?!

"No", he replied. He wanted his features because it provided him political insulation. There was no entrepreneurial spirit here. So, I created a small sign that hung outside my cube. It was a modest protest, but it was the only thing I could manage.

Buggy features made while you wait.
Buggy features fixed in about 6 months.

Can an entrepreneurial company that converts to a revenue producing company return to its entrepreneurial roots? Or, is the management structure of an R&D early start-up company and the management structure of a steady-state adolescent company so different that one cannot emulate the other -- even temporarily? Is such a state-change inside a company irreversible?

The story does have a happy ending. The company went bankrupt. But, in a package deal, the assets were sold to another group of investors. With all of the morons from Marketing and Sales gone, Engineering was able to quietly finish the product, fix the bugs, and resolve all of the outstanding customer issues.

As it turns out, all those features which were critical to the next sale actually weren't necessary at all. Most all of our sales prospects were happy with the product the way it was. Although they sometimes listed a couple of these features as nice to have, their absence didn't stop a single sale that I know of.

Engineering had built the right product; they just hadn't had a chance to finish it. But, once left alone, completing the project (and making customers happy) was just a question of hard work and solid engineering practices. That, I believe, is the most unsurprising part of all of this.

Ancestor Worship

I worked for an equipment manufacturer that was in need of their next generation product. The founders of the company created the first product and it held a special place in their hearts. Unfortunately, their romantic memories of the project were not always accurate.

I was recruited by the company to run the software department for the next generation machine project. When I arrived, the effort to scope the project and produce a proposal for a DARPA grant was in full swing. I spent my first few weeks talking with the engineers, gathering their input, and creating a master list of tasks that I captured on a set of white boards in a conference room adjacent to Engineering. I dubbed this place "the little nasty room" and the engineers quickly agreed that it was a room that was not much fun to be in.

Software scheduling is always a difficult activity. It is far too easy to miss tasks, underestimate the difficulty of things, and, in general, be too optimistic. This project had some extra pressures associated with it. The first problem was obvious: this was our second attempt with DARPA to get the project done. Our first attempt had been so horribly underestimated that it had no chance of success. Certainly, there was a strong desired to "get it right" this time.

The second problem was more subtle and yet more dangerous: nobody believed my estimates. They appeared to upper management, the ones who created the first machine, to be far, far too high.

The problem was this: they didn't remember how long it took to create the first machine, nor did they remember how many people worked on it.

Here's how I goofed up: I thought this was a technical problem. I thought that the problem could be solved with a simple memory jogging memo that reviewed the previous machine's construction and highlighted the task ahead for the new machine. I also threw in some other familiar data to help make my case. I came at the problem in a couple of ways:

  • Accounting for the previous effort
    I created a spreadsheet with the names of the engineers along the vertical axis and the quarters and years along the top horizontal axis. I then filled in the matrix. Johnny worked here 2 years, from here-to-here. Sally worked on the project 3 years, from here-to-here, etc. When I'd finished, I tallied the amount of time spent by the engineers (in total). It was something like 60-80 engineering-years. This was a number close to my estimate for the new project.

  • Typing fecundity
    We had software for the current machine. I did some measurements. If all we had to do was "type in the answer", and if the new project was only as hard as the original problem, it would take between 6 and 9 months of the proposed engineering team's time just to type in the programs! Forget about design time, test time, etc. It was going to take 6 to 9 months just to get the typing done! Certainly, this should help set a lower bound on any discussions.

  • Data from another, similar project
    As it happens, the management team (who had created the first generation product) had also overseen the development of another machine at another company. A couple of the engineers that had worked on that machine years before also worked on my project now. So, I did a spreadsheet to tally up the effort for that machine. Again, the estimate compared nicely to mine.

I put the finishing touches on my report, had a few of the engineers review it, and finally gave it to my VP in hopes of winning a little respect and support. Guess what happened...

... he buried it. He didn't show it to a soul. The bidding process for the contract continued and the project manager decided, unilaterally and at the last moment, that my submitted estimate was too high. In the end, my bid was cut in half. I was told to consider it a 'management challenge'. My VP (the one who buried my report) and the project manager (the one that cut my estimate in half) both left the company within a month after submitting the bid to DARPA, leaving me with a fresh death march.

The bidding process was only one example of the effects of ancestor worship. Throughout the ensuing death march there was a prevailing attitude from the first generation team that the second generation project team wasn't up to the task. Some of this might be explained by the antipattern below (Elitism and Jealousy) but the bulk of this attitude came from the notion that the new team, the rookies, couldn't hold a candle to the original team.

This project failed. In fact, the company failed as well. It has been over twenty five years since The Mythical Man Month was published providing Fred Brook's answer to the question "why does software cost so much?" and yet we are still dealing with management unwilling to live with the answer: it always cost this much, you've just forgotten.

Elitism and Jealousy

The last antipattern I'll discuss is Elitism and Jealousy. Creating this pattern is easy: split Engineering into two teams: one on the existing product and one on the new product. Or, just create an advanced development function and give new product development responsibilities to them. Finally, remove any Engineering management leadership, sit back, and wait. The fur will be flying in no time.

I was working for a small company in the mid-1980's that needed a next generation of small data terminal products. The original products, used primarily as credit card processing equipment in gas stations, was expensive to produce and unable to compete with some of the new offerings brought forth by our competitors. A fellow was hired as the Director of Advanced Development and charged with building a team to create the next generation of products. I was hired into that team.

The members of the original Engineering team were nonplussed by this sudden appearance of these upstarts. Why did they have to do all the "grunt work" supporting the old product while we got to "play" and create all the new, cool stuff? Hadn't they earned that chance?

Our (the Advanced Development team's) assessment of their work wasn't always complimentary. One of the reasons why the original product line didn't age well is because the Engineering team had been short on theory and long on "hack and wack". Their designs were old. Even their new efforts had too many parts and were difficult to assemble. The pin counts and part counts were too high and reliability suffered. They also didn't take advantage of some of the more interesting, and economical, technology to appear and, in the words of the company President, "they were putting a $20 bill in every box they shipped." The old designs in the existing products had problems and we called them on it. The war was on.

The Advanced Development group suggested moving to a new processor family to cut manufacturing costs, lower software development costs, reduce pin count, increase reliability, and reduce circuit board footprint size. The suggestion was dismissed out-of-hand by Engineering. We made other suggestions and other offers to help with the existing product line but these, too, were rebuffed. I don't blame them. A few ill-timed and obnoxious comments by a few Advanced Development team members towards the existing Engineering team had started a feud that would last long after my departure from the company years later.

The company's problems worsened. Sales now slumped badly from a crop of new competitors. Our costs continued to climb. Even the revenue we had was costing us money since we had negative margins on those products we could sell. Finally, convinced something had to be done, the President, several VPs (including the Engineering VP that had allowed the feud to develop and fester), my manager (the Director of Advanced Development), and a few others -- including me -- were summoned to a conference room for a "what are we going to do about this?" meeting.

The first question the President had was a good one: "what are our competitors doing that they can build these things cheaper, faster, and better than us?" Bored, and a bit uncomfortable in this meeting, I had been absentmindedly playing with my Swiss Army knife and the collection of competitors products arrayed across the conference room table. Finally, while the discussion continued, I took one of the boxes and began disassembling it. When I had finished taking the thing apart, I dropped it on the table with a thud. That got everybody's attention.

Inside this box was a design remarkably similar to the one the Advanced Development team had suggested. The Hitachi 64180 processor was there (the processor we had suggested) along with some of the other design changes we insisted would both reduce costs and increase reliability. Our competitors had done the same analysis the Advanced Development team had done and arrived at the same conclusions. The competitors had acted; we had not. As the quote at the top stated, "If you don't create the replacement for your current product, your competition will do it for you."

Again, showing my grotesque naivete, I thought this might settle it. Obviously we had the right answer now. We should do the right engineering thing, right? Of course not. This was never a technical problem; this was a people problem.

That company was eventually purchased by another company from out-of-state. The Advanced Development team quit one-by-one over the course of a few weeks soon thereafter. I was last to go. None of our designs, none of our products, ever saw the light of day.

This wasn't a technical problem. None of the previous problems were technical problems. We can say that these were management failures or a failure of leadership but that doesn't explain why they happened or hint how these problems might have been handled differently.

Managing Risks

As I stated in the beginning, there are risks associated with second generation projects. I've listed a few of them above but I'm certain there are more of these "antipatterns" out there. What other risks do these "second time around" projects have? How would you handle them? I look forward to your ideas.


  • AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis. Read the description on
  • The Innovator's Dilemma. Read the description on here.
  • Death March: The Complete Software Developer's Guide to Surviving 'Mission Impossible' Projects by Edward Yourdon. Read the description on and read my review here.
  • The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition (2nd Edition) by Frederick P. Brooks. Read the description on and read my review here.
  • See all of my reviews here.

Mike Woodhouse

Posts: 2
Nickname: mikewoodho
Registered: Mar, 2003

Re: The Second Time Around Posted: Jul 7, 2003 6:37 AM
Reply to this message Reply
There's a lot of truth in this. I was brought into a young company to take their product forward from its first, working but hopelessly inflexible version. Being less than enamoured of the abilities of the developers I was given permission to recruit, which I did. Three months later, the team I'd recruited had been so comprehensively mistreated by the management of the company that they left to set up in direct competition to their previous employers, doubtless reasoning that they could hardly do worse!

Moving to more general matters, I think the "difficult" second version syndrome may be so frequently experienced because the companies that get to the point of considering a second time around the block are those that cut corners to get something out of the door in the first place. How many "superbly-run" projects ran out of money before any code got shipped? A thought that starts me wondering whether (a) death marches are always necessary or (b) I was inaccurate to use the phrase "superbly-run" above. I wonder what the experiences of Agile startups has been?

Frank Sommers

Posts: 2642
Nickname: fsommers
Registered: Jan, 2002

Re: The Second Time Around Posted: Jul 7, 2003 11:58 PM
Reply to this message Reply
I had a very similar experience myself as well, working for a small company. I think the key to avoid that problem is to keep the momentum going, i.e., institute a "permanent revolution" (to quote Lenin) in the product development cycle.

The "permanent revolution" concept fits into the three-legged growth engine of a business: Getting more customers, increasing the dollar amount of each sale, and getting more money out of existing customers. I think it's not enough to focus on just one of these, but one must work on all three simultenously. One can fine-tune product development to serve these three needs.

Now that I work for an even smaller company, one of the ways we avoid hitting the follow-up release wall is to make releases very frequent. Since we did not know all there was to know about the business domain, we needed to work with customers from the beginning, as they have guided us through different product features.

In order to make customers part of our product development team, I started to think of our application as if we were building software for a Mars probe. In essense, we had to send something into the customer's territory early on. But we didn't know what that software will encounter, we knew only that it will need almost daily updates and bug fixes, etc. So we built a 2-way life-line into the product from day one (in fact, that feature was implemented almost before all the "real" features were ready). One way we are able to update the software remotely. The other way we get diagnostic feedback back into a database from every client installation. That's a pretty simple mechanism (in fact, you can probably implement it in a week), but it did help us. So now we can come up with continuous product updates.

Of course, customers would be totally confused if new features just started to pop up in their application every week. So we have a few early adopters, and we essentially give them the software for free for life. For this, they let us use them as Guinnie pigs for new features. When we have a set of those new capabilities ready, we just announce an upgrade, and customers that wish to purchase the upgraded version can use the remote update capability to download the appropriate version.

Ian Rae

Posts: 21
Nickname: ianrae
Registered: May, 2003

Re: The Second Time Around Posted: Jul 8, 2003 9:06 AM
Reply to this message Reply
> <blockquote>
> "If you don't create the replacement for
> your current product, your competition
> will do it for you."
> <br>
> -- Accepted product wisdom
> </blockquote>

One company I worked for built digital film recorders and did something quite unusual. They added delay code so their recorder, while still faster than anything else on the market, was processing images at half its designed speed. A year after releasing the product, when competitors started catching up, they simply removed the delay code and announced "Version 2.0 -- Twice as fast!" The lesson is: Don't release all your goodies at once. Keep some in reserve.

> This wasn't a technical problem. None of the previous
> problems were technical problems.

In a large part they are cultural problems. The sort of engineers & managers who design initial products can be the more entrepenurial and creative types, who don't stick around for subsequent releases. Then a different sort of group gets hired to maintain the product. It can be a mismatch to ask the second team to invent a new product.

Engineers think in terms of architectures while sales & marketing think in terms of customers and features. Many 'Second Time Around' product rewrites fail to cater to existing customers. Microsoft has done a admirable job in migrating their Windows API over the years. They have made major changes (16-bit, 32-bit, COM, .Net) but have provided good backward compatibility. This seems to be a sweet spot in product rewrites -- find a way to make it seamless for existing customers.

Alex Peake

Posts: 13
Nickname: alexpeake
Registered: Jul, 2003

Re: The Second Time Around Posted: Jul 8, 2003 10:19 AM
Reply to this message Reply
Looking at this another way would say that the second time around is actually the easiest! For example, following the idea of (Dick Gabriel):

"The concept known as “worse is better” holds that in software making (and perhaps in other arenas as well) it is better to start with a minimal creation and grow it as needed."

Given this, and given you (should) have lots of customer feedback from testing alpha and beta versions, you already have version 2 defined and ready to work on.

The failing, I believe, is that the definers of the "second round" are out of touch with their customers (often believing that they (the definers) know better than the customers).

Carl Hartwick

Posts: 2
Nickname: weblurker
Registered: Jul, 2003

Re: The Second Time Around Posted: Jul 17, 2003 2:03 PM
Reply to this message Reply
About that credit card processing equipment company you worked for, was that by any chance a company located in Toronto, Canada?

I worked for that company back in the mid 80's and your description matched *exactly* my experience, but I think it happened to me a bit earlier in their design cycle.

You may have worked for that company after I left and fought the same battle all over again. That might be an interesting comment on the longevity of a company's DNA once it's been cast at the beginning.

B. Scott Andersen

Posts: 16
Nickname: bsandersen
Registered: Jun, 2003

Re: The Second Time Around Posted: Jul 18, 2003 8:26 AM
Reply to this message Reply
> About that credit card processing equipment company you worked
> for, was that by any chance a company located in Toronto, Canada?

Nope. But, you're not the first person who has mentioned that
they'd had the same experiences described in this article (and
the previous one, too!). Some of the folks who have written
has said things like "it is spooky: its like you were talking
about my company!"

One of my points here is that this sort of thing is pervasive.
From some of the email I've gotten (and now your post), it
appears I may have been right.

-- Scott

Carl Hartwick

Posts: 2
Nickname: weblurker
Registered: Jul, 2003

Re: The Second Time Around Posted: Jul 18, 2003 12:34 PM
Reply to this message Reply
> > About that credit card processing equipment company you
> worked
> > for, was that by any chance a company located in
> Toronto, Canada?
> Nope. But, you're not the first person
> One of my points here is that this sort of thing is
> pervasive.

Well, I'm truly amazed.

Just to backfill, the Toronto company originally used the 8048 and then the 8051 to implement their product. We tried to convince them to use the Z80, but failed. When you mentioned the 64180, I had assumed you had tried again at a later date.

The other odd thing is that the restaurant management system situation you talked about also occurred here in Toronto, a friend of mine worked there as a consultant and the same thing happened to them, they waited too long to upgrade their product and disappeared.

A surprising instance of synchronicity. The same thing happened to two different companies that happened to be in the same business in two different cities. It makes you wonder about the pervasiveness of coincidence.

Flat View: This topic has 7 replies on 1 page
Topic: Buy Your Own Tools Previous Topic   Next Topic Topic: Java's Real Value Proposition

Sponsored Links


Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use