Paperback Version Now Available!

The Fable of the Farmer and the Fish

Paperback Version Kindle Version

All ages: K and above. Order on Amazon

A simplified explanation that even children will understand describing the fundamental issue behind the California water wars, the war between the protectors of the Delta in the North and the Corporate farmers in the South. The story shows why the Bay Delta Conservation Plan (BDCP) and Governor Brown’s Delta Tunnels are not the needed solution and proposes a real, long-term solution. Set in the format of a children’s book.

This book is valuable for all ages but simple enough for Kindergarteners. For younger children, it teaches the value of responsible sharing and the need to take care of our environment.

Proceeds go to Save the California Delta Alliance (STCDA).

It’s the Holiday Season!

At this time of year, companies often wonder what the “right” thing to do is. Should we put up a Christmas tree or would that offend the non-Christians? Should we have a “Christmas Party” or a “Holiday Party”?

Often it feels like a no-win situation: The avid Christians are offended by the lack of Christmas celebrations yet most companies, unless you are Hobby Lobby or the like, want to respect their diverse employee backgrounds. There’s complaining going on about Obama Administration’s use of the term “Holiday Trees”. It’s hard to tell what to do nowadays.

I liked the way we handled it at our start-up, Azerity.

There were three co-founders: A Catholic, a Mormon and a Jew. We used to laugh about it and wonder how that happened – how the three of us ended up starting a company.

In December the first year we were in business, Steve, one of the co-founders and CEO, came to me and said “Let’s go get a tree!” I was chosen because I was the one with the biggest car – a Volvo wagon we could load a tree in. (He and John both had BMers). It was a bit surprising since our CEO was the Jewish member of the triad. But off we went. He loved to grab the saw, find the right tree and saw it down.

Julie had a good idea – she asked Steve if he would like to also put a Hanukkah candle in the entry. We all liked the idea of having both.

As we grew in size, next to the tree in the lobby we added giving barrels (one for toys, one for food). The employees enjoyed going to the salvation army one evening and volunteering to pack gift packages for needy families.

On our reception desk, besides the Hanukkah, Ashraf brought in a Muslim shrine. Behind the desk were hung red envelops representing Chinese New Year and colored strings of paper celebrating Pancha Ganapati, the Hindu alternative to Christmas. The invitation was open to all employees to display items showing how they celebrated this time of year.

We’d top it off with a party at our CEO Steve’s home. We’d do a white elephant gift exchange, eat a lot and have fun. The first year of the company it was hard to get many of the Indian engineers out to any parties or after work events. Not all came to the first holiday party. But through the years we worked to let all employees and contractors know we really wanted everyone to feel a part of the company. My favorite memory was the year when all the Indian engineers showed up to Steve’s house in traditional dress outfits – the women in beautiful bright-colored silk saris, the men in long jackets with Nehru colors, silky pants and dressy sandals. We co-founders were very pleased that they all attended and even more so that they felt comfortable enough to come in their traditional fancy wear. We were one big family.

We didn’t care if someone said “Merry Christmas”, “Happy Hanukkah” or “Happy Holidays”. Everyone felt included and enjoyed a season of camaraderie and giving.

What is “Retired” in the 21st Century?

In 2007, after resigning from Model N (the company that bought my start-up Azerity), I established Duck Pond Software and wrote my first blog, “Retirement or Another Start-Up?” In that blog I wrote “My husband says I’ve “retired”. I don’t know what that means. The beauty of being in software is that as long as you have access to a computer, you can do all of the fun activities you did at your job (but just not get paid for it – humm.)”

Shortly afterwards, Model N asked me to return which I agreed to do as a consultant. It was part-time and in parallel I started blogging and creating websites for various groups including this Duck Pond Software site.

During a lull in Model N work in 2011, Freeman & I formed a partnership and created Software 2020, the 21st century tool to replace our SD Tracker bug tracking tool but expanded to support Agile and more. Then back to work at Model N as business picked up there.

Seven years later I did it again (terminated work with Model N) – not out of frustration with the company direction or technology this time. Before I left I was able to influence some important changes in company direction and to restore the product’s platform to a clean, maintainable architecture.

Feeling like I accomplished what I wanted to do at Model N and looking forward to a free schedule to do what I want to do when, here I am “retired” again. This time another start-up is not something I am looking for. Nearly 20 years of start-up life has been plenty. Nor is my goal being another VP of Engineering at a company I do not own.

I’m not void of work. Since 2009 when I learned about the state’s plans to ruin the Delta where I live in order to send our water south to benefit primarily rich agribusiness corporate owners in the Central Valley in their never-ending expansion to sell almonds to Asia for significant profits, I’ve become somewhat of a water activist, focused on Delta water issues and on stopping the BDCP’s Delta Tunnels. Being President of the non-profit Save the California Delta Alliance (STCDA) takes a lot of my time.

Also there’s boating and golf and travel and grandkids.

Will that be enough?

Probably not. I am a software evangelist. It’s in my blood. With the internet it’s easy to continue the discussions, mentoring of new engineers and managers, and hopefully help improve the current software methodology.

At Azerity, Anita and I implemented our own version of software process for start-ups. Later we coined it “Practical Software”. When people saw how we worked, they said “Oh, you use ‘Agile'” and we said “Yes, we are agile” but had never been involved with “Agile”, the new software process movement. Later I took “Agile” training and said “Oh, that’s basically what we used to do.” I found that the while the core of Agile is good, it is missing a lot of the practical basics. Upon retiring, the engineers I’ve worked with are all emailing me about how much they’ve learned working at Azerity and brought with them to Model N. There are lessons learned I’d like to share with a wider audience. Definitely more blogs.

Maybe I’ll finally write that book!

It doesn’t sound like retirement, does it? But then with the Internet, what is “retirement”? Anything is possible.

Getting Control of those Pesky Bugs

Some teams seem to have a very hard time managing their bug process.

Even teams who implement good processes sometimes have setbacks when budgets get tight and trade-offs are made. In large and small companies, often management pushes for more features so sales has “new stuff” to sell and bug fixes go by the wayside. Sometimes the code itself is not good due to a rush to get something out-the-door. Teams often end up with a huge technical debt: piles of bugs that need fixing; code that is brittle and hard to maintain.

The team I’ve worked with for 15 years has implemented great processes and tools to stay ahead of the game. Through the years we’ve learned what works and what doesn’t. Here’s a list of do’s and don’ts to stay ahead of the “Technical Debt” debacle.

How to avoid Technical Debt in the First Place

Avoidance is the best policy. It’s really not that hard. Here’s what you need to do:

  1. Code it right the first time. There is no such thing as a “working prototype”. Prototypes end up being the real code. They were just implemented using shortcuts and temporary coding techniques and will end up becoming a huge technical debt.

  2. Keep it simple. Don’t build functions that are more complex than needed. Some teams get too creative trying to build elegant and esoteric software that instead ends up hard to maintain with many features that are never utilized by clients. Don’t use rocket science if you aren’t sending up a rocket. Keep it simple.

  3. Incentivize developers to find their own bugs. Make it part of the company culture that developers do their own unit tests instead of assuming that QA and automated testing will take care of finding any issues. First, bugs are cheaper to fix the earlier in the development cycle that they are found. Second, developers who are trained to produce quality code instead of lots of code will end up producing products with less technical debt.

  4. Never release code with “known issues”. If your company is used to putting out release notes that include a list of problems/warnings for the clients, you’re in trouble. Contrary to some manager’s belief, it is not only possible to deliver bug-free code, it’s the only smart thing to do.

    Let’s quantity that. That does not mean we need to test to the level of standards that are required for space software that can’t be repaired in space or for medical tools which, if they error, will cause human harm.

    It means testing to the level that is commercially acceptable and fixing what is found with a reasonable amount of test cycles. Yes, the clients may still encounter some new issues based on different configurations and usage. Fix those in the next maintenance release.

    But we never, never find problems during testing that users will encounter which will impact their work and deliver anyway just to meet a schedule. If we continue to hit those kinds of decision points, it means we are not scheduling enough time for adequate test and related fixes.

  5. Think long-term. Besides thinking about the functions and new features to be available with this release, think about how your clients will use the system long-term and build your software so they can easily implement and then upgrade from one release to another. This was overlooked during the 20th century by most vendors, particularly the big ERP solution providers. The big gorilla ERP software vendors made a large proportion of their profit from services: Implementation and upgrades. I call that spending money on no-value-added services. I think that is wrong and should/can be avoided.

    In this century, with the advent of cloud computing, software vendors are having to figure out how to make it streamline and simple to upgrade. Finally. But if you are building on-premise software or your systems that need to be integrated with other systems and periodically upgraded, think about ways to make it simple for your clients. It will save you a significant amount of bug-fixing time in the long-run.

    If you don’t have the developer expertise to do that, I recommend you look at building your software on a cloud platform like Salesforce that provides upgrade functions and features with the platform.

  6. How to dig yourself out if you have Technical Debt

    What if you find yourself in a group with significant technical debt? If you’ve decided you need to get rid of your huge pile of bugs, you may find yourself spending inordinate amounts of time and effort sifting through the bug calls, listening to client complaints and trying to prioritize which bugs to fix first.

    Instead, start with a process and stick to it. The best way to get out of your hole is to stop digging.

    First you’ll need to decide if you need any major re-architecture projects. If you’re an IT team, you may need to look for a vendor solution to replace your in-house tools. Look for one from a company with good processes and clean software.

    If the problem is a huge pile of unaddressed bugs and customer issues, here’s a good approach:

    • Gather together a cross-functional team with representatives from your services team who represent the client, the developers, product management/marketing and QA.

    • Take one pass through your open bug list pile, mark each one with three identifiers:
    • Severity: How bad is this bug?
    • 1 – Critical. A client’s production system is down or data is being degraded. Must get fixed ASAP.
    • 2 – Serious. The bug is causing or will cause issues for clients.
    • 3 – Non-Critical. This is a cosmetic issue or else buried in a place where users are very unlikely to go.

    • Priority: How soon do we need to fix this bug?
    • 1 – High. Needs to be fixed ASAP.
    • 2 – Medium. Shouldn’t sit forever, fix when we can.
    • 3 – Low. Fix when there’s time. No big rush.
    • Priority and Severity are normally not coupled. Normally a Severity = Critical will also be Priority = High unless, perhaps, the data degradation isn’t occurring because the client hasn’t turned on some related function. Otherwise there’s little linkage. Even a Severity NonCritical bug could be Priority “High” if it is a misspelling that makes the company look bad, for example.

    • Release: What release do we assign it to?
      This step assumes that, in addition to doing your regular enhancement releases or agile iterations, you are putting out regular maintenance releases. The bug fixes that are not associated with new enhancements should be assigned to release “piles”, leaving some bandwidth in each for unexpected issues.

      Assign to upcoming releases based on a combination of Severity and Priority. Lower Severity and Priority items can get put into a maintenance bucket to be worked off after the more important ones are done.

      Why? Because if these are not assigned somewhere, the team continues to thrash through them, again and again. If they get assigned, even if some adjustments are needed, we have a sense of when fixes can be made available for the user.

    • Hold weekly or bi-weekly SDRB Meetings. Once or twice a week, a cross-functional team should meet to review all of the new issues. This should be the highest-level person responsible for the product area. For example, the QA Director, VP Engineering and/or product lead, Director of Product Management, etc. When our company was small, even the CEO sat in periodically. We call this team the SDRB (Software Development Review Board) and they have complete power for making decisions.
    • Together we decide if they are marked with the right Severity and Priority.
    • Together we assign them to a specific release.
    • There. Done.
    • Instead of continuing to look at them and thrash through them again and again, they are ready for developers.

    • Train the Developers in the Process:
    • Only work on bugs assigned to the current release.
    • Never, never change the Severity or Priority or Release of a bug – only the SDRB can do that.
    • If you have a question, assign the bug to the product manager to answer it. It’s helpful if your bug tool captures comments so the product manager can respond and assign it back to the developer.
    • Note in the tool what you did to fix the problem. We also put our bug number in the code itself so later we can tell why changes were made.
    • When the code is checked into the code repository, the bug is marked “resolved”.
    • When it has been tested, the bug is marked “closed”.

    It’s best if you have a good bug tracking tool that allowed you to change assignments and ask questions, capture all comments, and record history. At my company we used the in-house tool SD Tracker. That tool was the impetus for building Software 2020.

    Regardless of what tool you use, everyone needs to use it and it needs to be easy and effective. It can be done with spreadsheets – it’s just a lot harder.

Is there a role for a Requirements Document in Agile?

My answer is “yes” but not the old type of Business Requirements Document (BRD). I think there is a role for a new type of on-line BRD – one that can easily evolve during the project. Some argue that TDD is replacing this need. But I think there’s a place in the Agile process for capturing the business requirements/information in parallel with the development tasks that ends up on-line and useful/readable by all. It happens DURING the process, NOT up-front.
No documentation

I think anyone who believes in Agile knows that the biggest problem with a big fixed documentation up-front, especially in Word, is that it gets out-of-date quickly and then is just a pile of often-misleading words. OR it’s held as the “bible” and then people become possessive of it and build some big process about how to any requirements mismatches, design flaws, etc. become change request-type issues and there we go – Waterfall all over again.

I believe the BAs/PMs are more likely to feel they can retain project oversight if there’s an on-line tool to track the product backlog (in high-level terms) and bring forward when time to implement it and where you can expand/refactor/capture details as you go along. Where stories can evolve into an on-line knowledgebase/repository that people (like the Call Center, Services group, new hires) can read and reference.

Of course, all projects, Agile or not, have requirements that are (hopefully) based on business needs. Some teams are struggling with their PM/BAs wanting to create a large document at the beginning of the project containing detailed use cases with every possible variation on every requirement. Some are having trouble convincing the PMs/BAs that a Product Backlog with user stories instead of fully documented use cases is a suitable method, with detailed analysis taking place during a sprint.

I think the hesitancy from BAs/PMs is a feeling of a loss of control when they are told to just write down “I want this …” stories, put notes on a board and work “in the air” (verbal communication mainly, not written). Some may argue that is a “lack of trust” – but I argue that PMs are also builders/designers who want to end up with “their” product at the end, their BRD. That still can be a valuable artifact. As long as it’s something that evolves with the product seamlessly and isn’t a wall blocking the project.

That’s where Software 2020 fits in beautifully. The prior blog, “Automatic Documentation – How we use Software 2020 to build Software 2020” describes the automatic way to use Software 2020 for tracking tasks, communicating between the team members (PMs and Developers) resulting in both an outstanding product and nice on-line knowledge base repository (aka BRD).
Software 2020 on-line spec

Software 2020 provides rich text online storage that is:

  • Easy to maintain
  • Easy to track
  • Easy to priortize
  • Searchable and sortable
  • Can Documentation be part of the Definition of Done?

    You might think I’m obsessed with having good specs and system documentation. I’ve blogged about it enough. I’d answer that it’s not an “obsession” but that it just makes good business sense. Even stronger than that – I do not think most software companies can operate effectively without on-line access to the final requirements specification.

    I’m not referring to User Guides or System Administration Guides that can written by tech writers after the software is complete by using the software itself. I’m talking about the specs that capture the business requirements behind what the code does including all of the possible business variations and configurations that needed to be coded for. That documentation is very tough to write after-the-fact, especially if the code is complex and has a lot of parameters, switches and properties to support different customer configurations and business uses.

    Why do we want it?

    Why would we want to end up with accurate requirements/design documents? I asked some key individuals if they thought that requirements management was important. They all worked in a company used to having an on-line requirements management system integrated with their mainline software development process resulting in clean, accurate on-line requirements specifications. Their comments:

    • [Development Manager]: Our specs are absolutely fabulous for requirements tracking and as a reference/knowledge-base. For the entire company. It is a must for any software company…
    • [Developer]: I think it’s critical to have documented what the software is to do so the developer knows what to do and the QA team knows what to test. Having accountability is huge.
    • [Call Center Manager]: Without documented specs, only the developers can support the software – that’s not efficient.

    Why doesn’t everyone have it?

    Why don’t all companies have good up-to-date on-line specifications?

    • It can take a lot of time and effort to keep specs up-to-date
    • Particularly if the spec is written at the start of the project, as the product evolves or changes occur (as they always do), the spec becomes out-of-date.
    • Inaccurate specs are just a pile of words – worthless.

    Because of the above issues/difficulties creating and maintaining good documentation, most Agile proponents advocate doing away with specs. I think that’s “throwing out the baby with the bath water!”

    We developed Software 2020 to fill this void, solve this need. Before Software 2020 we did it with DOORs Requirements Management System and our internal SD Tracker plus a lot of manual effort and manual linkages. But it was worth it even then.

    What Makes a “Good Spec”? Accuracy!

    I’m convinced that to maintain good, up-to-date, accurate specs, producing specs must be part of the process. Developers need to use them while they code. The specs need to be on-line and able to evolve as changes occur from the product owner or from feedback by the developers. They need to be tested for accuracy as part of the QA test process. Every new change needs a link to the coding task that will implement it.

    Good specs are living, breathing documents. Good specs are part of the software process, where the entire team takes ownership and responsibility for their accuracy. That doesn’t mean that there is added work, rather that when used for reference (by anyone – the call center, developers, testers) if the code doesn’t match the spec, a task is created to resolve that mismatch.

    In an Agile environment, why can’t Specs be part of the DoD?

    If specs are just part of the Definition of Done (DoD), two scenarios are possible:

    1. The become inaccurate over time because they are not used during code development, changes aren’t tied to specific code tasks, and aren’t part of the test plan.
    2. ELSE the process could require the Product Owner to add all final changes/updates to the existing specs, the developers to review all changes and QA to verify as part of the DoD. However, this will end up being a significant added cost and I contend that this kind of after-the-fact effort will not result in as accurate or complete a spec as a process where specs are used during coding and during test as part of the process.

    Related Blogs

    Lessons from the Moon. Gotta have good documentation!

    A YouTube video is circulating: How to Get to Mars. Very Cool!. It reminded me of the joy of my early years working for Ford Aerospace with satellites and satellite designers. Such fun.

    Intelsat 5 Satellite
    Intelsat 5

    At one point in my aerospace career, I was the project lead managing the Ford Graphics CAD/CAM systems. These were big stroke graphics tubes Ford Motor used for designing cars. Ford Aerospace wanted to see if they would be as productive for the satellite designers. The Ford Graphics tubes were as precise as designer drafts. Unlike raster graphic terminals, they used unique vector graphics.

    Looking at this Mars video I remember one great designer, John Giassi, who described the technical difficulty of designing the stow point hinges required in order to fold up the satellite antennas and solar arrays so they would fit inside the launch envelop in the rocket cone.

    Intelsat 4A Sketch Intelsat 4A being built
    Intelsat 4A being Designed and Built

    The hinge had to be done correctly. Once a hinge wasn’t designed quite right so the mechanic on-site had to push it physically to get it in it’s final position. In orbit the array wouldn’t unfold, couldn’t stabilize, and it wobbled off orbit into space. Not good after 3 years and $3 million dollars investment (and that was 1980’s costs)! Using the Ford Graphics system, a stow point error in the Intelsat VA Satellite was found and resolved on the “drawing board” prior to fabrication.

    Looking at the video amazes me at the design that has to go into the mechanics to unfold a system as complex as the Mars Rover!

    The other story this video reminds me of is one that was told by the Ford Satellite designers about an early rover built by a competitor. Lunar Rover The rover successfully landed on the moon and carried out mission after mission. Each new mission was designed by the ground scientists based on previous tests and findings and would be uploaded into a special area of memory for missions.

    Unfortunately, the concepts grew and the scientists eventually designed a mission that was too large to fit in the memory allocated. They scrambled to find a way to carry out this next important mission. The designers looked through the rover’s specifications and finally one bright engineer said “Aha! We can reuse the memory where the landing coordinates are stored. We’ve already landed so we don’t need those any longer.” Excitedly they went to work. When ready, the new program was updated and stored in memory.

    At that point the lunar went dark. No transmissions. What happened? The team went into panic mode trying to find out.

    The answer was simple. There was one other function the landing coordinates were used for – an undocumented function. The coordinates were used to let the lunar know where earth was, where to point it’s antenna for communication. Once the memory was overwritten, the rover pointed it’s antenna to some unknown point in space, forever awaiting its next mission.

    Guess no one thought anyone would be writing to memory not allocated for missions!

    If you liked this post and the video, check out No Ordinary Moments, my reflections about our trip to see the launch of a satellite and the excitement of the young entrepreneurs who were counting on it for their start-up’s future. And if you want to know how to document easily, automatically in an Agile or non-Agile software world, see Automatic Documentation – How we use Software 2020 to Build Software 2020.

    What not to do on your first job – Don’t Make Assumptions

    A college grad arrived on his first day at work to report to his new supervisor, Saul.

    Just before he arrived, Saul’s manager, Glenda, went to their admin’s desk and sat down to jot down a note. Just then the college grad arrive with a big smile, eager for his first day.

    “Hi,” he said to Glenda. “Is Saul in?”

    “Yes, he’s in his office,” she politely responded.

    “Would you tell him I’m here?” he asked.

    “Sure,” she said smiling. She was going to head past his office on the way to hers.

    “I guess you’re the admin, huh?” he said beaming with excitement.

    “Actually, no, I’m Saul’s boss.”

    The poor kid almost passed out, went ten shades of pale, groaned, stammered. He was sure he was about to be fired on his first day. Glenda just got up, chuckled, and headed back to tell Saul his new hire was here. She kind of liked him.

    Do we too often “Assume”?

    On a linked in group, a women engineer started a discussion about how she’s tired of the computer science world where men treat her rudely, make inappropriate comments, etc.

    One fellow posted a comment. He said he was about to graduate with a BS in Engineering and he wanted to be sure he “treated the girls they way they want to be treated.” Ho boy. Did he get an earful about the proper way to address a “woman”. He was confused. “But you call us ‘guys’, isn’t it OK to call you girls?”

    “No,” the answer quickly came back. “Would we call you a ‘boy’? What’s important is equal treatment. If you call yourselves ‘men’, call us ‘women’. If you want to be the ‘guys’, then we can also be part of the ‘guys’ or ‘gals’ but not, not ‘girls’.”

    The poor lad was quite concerned. “Gee,” he commented. “I’m not even out of college and already I’m making tons of mistakes.”

    “No worries,” they said. “Just pay attention and treat us equal. I’m sure you’ll do OK.”

    A Tale of Two Universes (Selling “Vaporware”)

    We’ve all heard the term “vaporware.” Software companies are notorious for selling it. It has become such an invasive practice that customers expect it.  

    It seems all right at first. The Sales guy has a hot new client. The software “almost fits” their needs. It’s just missing a few fields here and there, a little function over here, one over there. He sits down with a member of the engineering team. “Can you mock up what this would look like?”

    “Sure,” says the engineer. “That would be pretty easy to add on.”

    “What about this function over there?”

    “No problem,” says the eager engineer. He can envision how it would be implemented and it isn’t that large a stretch.

    The Sales Rep goes off to his next customer meeting with his “demo” and powerpoint slides in hand.

    “See – we understand your business issues, we can take care of your needs.”

    The customer debates a bit but three months later, the contract is signed, software purchased.

    The Implementation Team has been selected. Before they head over to the customer site, the Services Manager calls the Services Lead into his office. “One thing you should know. The customer thinks the product does this and that and has these functions.”

    “What?” says the concerned Services Lead. But it doesn’t!”

    “Can’t you just configure it on the outside?”

    “It doesn’t work that way! We need some product changes.”

    “That’s OK – the engineers said it would be easy.”

    The Services Manager goes to the VP of Engineering. “When can we have this product upgrade?”

    “Product upgrade? We’re just starting final test right now for our major release. If we put this in now it would delay the release significantly and we have customers who are planning on this schedule.”

    “But it’s a ‘must have’ for our new customer. Sales committed to it!”

    The Executive Committee has an emergency meeting. Engineering is directed to create a branch in parallel during their final test sprint to try to get these features out right after the main product release, against their policies. The new features will be released 1 month after the major release.

    The concerned Services Lead is told that they will just need to “fudge it” for the first few months of the implementation project.  

    “It’s OK”, says their Manager. “The customer is using the Waterfall method and are first going to firm up their requirements, then spend a couple of months on detailed design. By then the release will be ready.”

    An uncomfortable team heads over to the customer site with their instructions. They had been directed that during requirements review, to pretend that the features are in the product and check off the requirements associated with the new fields and functions as “OOB” (out-of-the-box). “It’s all right”, they are told by their Manager, “because they will be in the product real soon.”

    During the detailed design phase the customer starts asking to see the product to help them envision the customization changes they are designing. The Services team knows many of the big features they expect to see there just aren’t there. There’s tap dancing.

    Eventually the customer figures out that the software isn’t all there. The truth is out. There is a huge blow-up and the customer calls the CEO to complain. The CEO assures them that their features will be in the new release. They are still upset but sit down with the frazzled Services Lead to iron out what a viable implementation schedule would be including incorporating the upcoming product release. They start their work on the current release for customizations that don’t require the new features.

    The new release is delivered and the customer’s policies require a total re-test. While re-testing they uncover minor changes in the completed configuration needed due to the new product enhancements not being exactly how they’d envisioned them. Because of re-testing and re-work, both cost and schedule are impacted. Although the contract was “Time and Materials”, they call the CEO and refuse to pay any extra cost due to re-work and he concedes. Still the project costs them more money than planned due to the schedule impact.

    The customer isn’t happy but is used to software companies that are less than truthful. Standard practice, they grumble. The skilled Services team eventually delivers the final solution but the customer is less than thrilled.

    Replay in a Parallel Universe

    The Sales guy has a hot new client. The software “almost fits” their needs. It’s just missing a few fields here and there, a little function over here, one over there.

      He sits down with a member of the engineering team. “Can you mock up what this would look like?”

    “Sure,” says the engineer. “That would be pretty easy to add on.”

    “What about this function over there?”

    “No problem,” says the eager engineer. He can envision how it would be implemented and it isn’t that large a stretch.

    The Sales Rep sits down with the Engineering Manager. Here’s the features and functions that Client X will need if they buy the product. Is it feasible to get them into the current release?

    The Engineering Manager and Product Manager have a quick meeting to determine the feasibility. They will need to move some features out of the current release now to make it happen but there are no clients waiting for those. She gets back to the Sales Rep with an “OK – as long as the customer can commit within the next few weeks while we still have a few Sprints left.”

    The Sales Rep goes off to his next customer meeting with his “demo” and powerpoint slides in hand.

    “See – we understand your business issues, we can take care of your needs. These few functions are not in the software yet, but if you buy the product the Engineering Management team has agreed to provide them in the next release which will meet your schedule. If you can sign the contract this month.”

    The contract is quickly signed, software purchased.

    The Implementation Team has been selected. During their internal kick-off meeting, before they head over to the customer site, the Services Manager calls the team into his office. “One thing you should all be aware of. There are a few features that are missing from the product but engineering has already agreed to deliver them in the upcoming release which meets the customer’s schedule. The Product Manager will work with your team and your customer to make sure we build the features the customer is anticipating.”

    “Great.” says the Services Lead.

    During the detailed design phase they start reviewing the product and proposed changes. The customer can provide input into the new features and iteratively they improve on them before the product development team has started their coding. In fact, they find a way that the product changes can be implemented that remove some of the customizations that had been bid, saving the customer implementation money.

    The project is completed on-time. The customer feels they are part of the team and the vendor is the best vendor they’ve ever worked with. They will definitely consider this vendor for their next project.

    They are happy to give a Press Release and authorize a marketing blurb for the vendor’s website.

    Why Sell Vaporware?

    Why do software companies feel they need to sell vaporware? Some misguided notion that customers won’t buy a product unless it has all features today?

    The second scenario brings everyone on-board. The company is collaborating. The customer is respected.

    Having worked on projects sold both ways, I can attest that the second, honest and up-front scenario is by far the best.

    Story of a “Successful” Off-Shoring Experience

    “Software Companies need an Off-Shoring Strategy”
    (or so they were saying)

    In the start-up I co-founded, our CEO (and my partner) was pushing hard for an off-shoring strategy. This was the late ’90s/early 2000’s and the buzz in the software business was that the way to grow quickly and cheaply was using the Indian offshore companies. He would regularly send me emails saying “5 skilled programmers for $15/hour” whereas compared to the rates we were paying was a significant reduction. Reading further, there were additional management costs but but still seemed impressive. In addition, this was still during the boom and local talent was hard to find. (I’d remedied our lack of hires by partnering with a local Indian contracting firm who was providing us with developers where the contracting firm held their H-1 Visas).


    I felt inherently that it would be difficult to build a team off-shore but had no concrete reasons for my reluctance so I attended a couple of seminars around offshoring.

    • Many presenters gave facts and figures on the great cost savings. The Indian consulting firms described how cheaply they could provide CMMI Level 5 qualified work. (Since in my early years I was involved in the development and use of SEI Assessments, the predecessor of CMMI, I seriously doubted their Level 5 claims and believe it was more like ISO 9000 where everyone is trained about the steps – how to check in code, how to do code reviews – but not that the development and quality is superior).

    • The large software firms spoke highly of their cost savings. Most had large facilities they owned, operated, and managed where they sent software for final testing or had customer support centers.

    • One presenter discussed how to set up your own facility in India which included numerous lengthy trips to India and the mandatory bribes and dinners with various officials in order to get anything done.

    • Another presentation covered how to set up a “lease-to-buy” program in India, where you’d partner with an Indian firm who would set up a facility, hire resources including management, work with you to train them with the goal of transferring the facility and resources to become employees of the company. That sounded the best but still involved a great deal of up-front negotiations and travel. Until the team is turned-over to your company, there is an overhead fee paid to the services company including equipment and facility costs plus service company fees.

    • I met one person from a small company who swore that offshoring was the way to go. Digging deeper I found that the product expert for their company was located in Russia and he had hired, trained, and was managed their offshore development team from the company’s inception. Their main difficulty was how to train the U.S. Sales and Marketing people but solved it by having Sales and Marketing travel to Russia periodically. An entirely different situation than I was faced with.

    • All presenters from small-to-mid-size companies discussed the high turn-over rates and large yearly increases the region was currently experiencing due to the big corporations, like Oracle, that paid more and that Indian engineers felt gave them better prestige.

    • In addition, the presenters all had similar statistics regarding the number of managers needed per developer, additional cost for up-front design, and percent slower ramp-up of skills resulting in less productivity for longer duration.

    I documented my findings regarding what it would cost our company to set up a reasonable off-shoring arrangement versus hiring locally. Being a start-up with very few people, none of us would have time to travel to India and do the full-time effort required. At our early start-up stage with only Angel Investors we did not have the capital to initially buy a building so I analyzed the “Lease-to-Buy” option with a three-year turn-over. Besides the actual developer hourly rates, costs include:

    • A new local manager position (part-time)
    • Significant travel budget
    • Service company overhead and fees
    • Local manager
    • Average turn-over rates for India resulting in additional new hire travel, training and resulting loss of productivity during ramp-up
    • Yearly increases
    • Loss of productivity of the local team’s time that would need to be spent with remote conferencing, training, and travel
    • Average productivity and quality figures

    Needless to say, the yearly costs were nearly equivalent to hiring less developers locally and didn’t improve significantly after the group became employees, although at that time the potential to lower turn-over rates due to stock options and other benefits increased.


    My CEO agreed. It was an invalid business proposition. We hired locally.

    New Company – New Strategy

    When our start-up was acquired, the acquiring company had an outsourcing strategy in-place for its existing product line. Their offshore team performed testing only. Because of the size of that product’s software platform, each remote tester required local hardware and software requiring extensive Build & Release personnel and policies and high-speed dedicated networking from Corporate to India. The company had decided that the city they’d chosen was not a good choice, suffering from high turnover but lack of local talent pool. Plus the infrastructure there was not sufficient.

    They chose a new partner in Hyderabad for a Lease-to-Buy plan. Their goal was to move all development and maintenance to India with the exception of new technology development. I was given directions to develop an offshore team for our product line as well.

    Prep Work

    I hired our company’s prior VP Engineering as a consultant to help me with the initial 3 months effort. Together we put together the hiring plan. She coordinated updating and enhancing the Developer’s Handbook and other on-line documentation and development guidelines. She updated our software process to incorporate the offshore efforts and put together the training program and travel requirements. Fortunately we had a very good process (many of the tenants of “Agile” but not Scrum). We had good tools to aid with the process: Our proprietary tracking software (SD Tracker), PerForce for code check-in, and Telelogic’s DOORs Requirements Management system (since purchased by IBM). All three had web-based interfaces which was key for remote development. SD Tracker had ongoing comments section which greatly aided on-line “discussions”, capturing what was discussed and decisions made.


    We would start with only two developers, one tester and one manager who would also need to do hands-on development part-time. The other product line was much larger and had a significant hiring plan. The two product line teams, though, would remain independent since the code was very different. The hardest position to fill was the overseas manager. He/she would be key to the success of the project since he/she needed to be technically skilled to lead and train the new hires plus a good manager. I quickly learned that in India, the engineers do hands-on development work for only a few years then have the goal of becoming a manager. Managers there do not do hands-on development work. Finding someone willing to do both took a lot of convincing, but we were finally successful. The developers and tester were also hired and all four came to California for two months training. The manager had family in India and ended up having to return after six weeks. We were fortunate that he was extremely bright, picked up the basics and the deeper requirements, and although he still was a bit reluctant to go back to development, agreed to try for a year at least.

    After the team returned to India, there was a focus on continued communication. One of the lead developers was given responsibility for managing the Indian team half-time (coding the other half). She traveled there and spent a month on-site. Upon her return she regularly scheduled nightly conference calls weekly or more as needed.

    End-of-year Statistics

    Regardless, ramp-up was slow for the developers. After one year I found the developers were only 20% to 30% up-to-speed whereas in one year local new hires would have been at least 50%. (The software was complex). I also tracked the time I was spending providing additional design documentation versus what would be required locally but also many questions that seemed to require a simple written answer ended up looping several days before it became clear or a conference call was needed.

    After a year, one of the developers was deemed unable to perform and was moved to our services team to work on implementation code and a new developer hired and both developers were brought to Corporate for training/re-training. The manager was unable to travel due to personal reasons but had proven himself to have been a valuable hire. A few months earlier, at the end of our release cycle, his team was not able to complete some of their assignments and he jumped in and completed not only his own but any outstanding work. His code was reliable and high quality which is the only reason the release was successful. At that time I discovered that the services company was paying the manager the same low rate as the two developers (since he was also developing) instead of the manager rate I’d agreed to. I was furious and demanded they immediately provide him the raise and feared losing him so also spent time talking to him and making sure he was happy and letting him know how pleased we were with his efforts. Over the next few years the team was expanded slightly (3-4 developers, 2 testers) with the average amount of turn-over and salary increases. The manager remained.

    Ongoing Travel, Communications, Travel, Communications

    People were continually going to/from India. Any of our Indian engineers who traveled home yearly would take an extra few weeks to go to the site to work/train. All managers (including Directors, VPs) went there at least yearly. The CTO moved to Israel where he was responsible for all Indian operations. Plus yearly we would bring everyone to Corporate to work for a month or so.

    The company implemented it’s “Buy” option and all of the offshore team became employees. Plus they have been raming up the size of the offshore team.

    Changes Needed with Agile

    Then the company introduced Agile. Initially they tried to use the DOORs Requirement System to capture Stories in a separate spec but that was not a good process. First, DOORs doesn’t have an easy way to prioritize and sort requirements so the Product Marketing team (who performed as Agile Product Owners (POs)) exported the Story doc to Excel then went back to update DOORs with the Story Points and other changes agreed to in team meetings. They still needed to update the actual product specs in DOORs and now the tasks in SD Tracker were linked to stories and specs. But the biggest issue was the difficulty in working with the offshore team starting with Stories. They were used to working from detailed specs and the added interaction between them and the POs caused significant time delay. The company smartly decided to hire POs in India to work locally with those teams. For the next release, the company moved to Rally for Agile Story Management. This was much better than DOORs and Spreadsheets since Rally had a prioritization tool and the features one would want to manage Agile Stories. But, unlike real product documents, the Agile Stories, though grouped in Epics, don’t maintain a specific logical readable order – they remain distinct stories. In order to still communicate the business basis, the POs first wrote extensive PRDs using Microsoft Word. Those would be attached to the Epic. The features within the PRDs became Stories in Agile. In order to provide better clarity, extensive Conditions of Satisfaction (COS) were added as validations. To accommodate this, a design sprint was added as Sprint 0. Of course, quickly after the project started, those stagnant Word documents became out-of-date and useless.

    Both product line’s Product Management and Engineering Management and the VPs of both organizations spent several weeks in India to kick-off both new releases Sprint 0’s and to train/re-train. Having a local PO improved (but did not eliminate) communication issues since the Indian PO while very intelligent and eager, had a significant amount of information to learn before he could be effective. Local Product Marketing managers typically took 1-2 years to become effective and still didn’t know the breadth of the product after that time but had local product experts to interface with which the offshore PO did not. While I believe a local team could produce deliverable code in a sprint, the use of locally disperse teams requires the addiction of 3+ “Test Sprints” after code complete. This then is more of a hybrid model than strict Agile but seems to be working fairly well. The Product Line has two separate Agile teams including PO(s) and Scrum Master – one at Corporate; one in India.

    Same Conclusion

    Bottom line – I think this offshore team is as effective as anyone could hope an offshore team to be. A form of “Agile” is being performed, although it is currently not as effective as our prior Practical Software Methodology (an Agile-like process) with a single local team.

    There is substantially no cost savings overall.

    There is more work for the POs and development manager than interfacing daily with a local team plus ongoing travel costs and interruptions. Particularly when “Offshore” is half-way around the world and trips there require weeks due to travel time.

    More effort to complete, more miscommunications, less product delivered.