Interesting since I’ve been thinking a lot lately about the tortoise and the hare. You know the old adage – where the hare is fast and quick to the finish line but the tortoise wins the race. Initially one has to think about the “Agile” (i.e., hare-like, fast and hoppy) software development methodologies vs. the old school “Waterfall” methods. Yes – the waterfall methods were somewhat like a tortoise but they were worse, more like a tortoise that had to stop every few steps and wait for the gate to open so he could continue on to the next phase of the journey.

The problem I have with “Agile” technologies is the somewhat “gleeful” rejection of any and all documentation. “We are going to be a small team so we’ll just have discussions and come up with the right answers as a team.” Yeh, right. What happens when you need to do updates to your software. Is this “real” software that has users and a next release? What happens then? How does anyone know what the software actually does if it was designed and developed by committee and no document artifacts remain that accurately reflect the software “as built”.

“As built” documents are key to (1) accountability (for marketing, developers, and QA) and (2) an understanding of what the software is supposed to do so that knowledgeable changes can be made and (3) resources so that Technical Support/Customer Services can answer the call about “Is the software supposed to be doing this

I don’t think “Agile” is “Practical”. See our Requirements Management blogs for better ideas about how to really be quick-on-your-feet, focused, and develop high quality and low-cost software !

It’s really an architectural marvel. Such a beautiful design but was quite a construction feat. We took the tour and found out about the history of the building. There was a competition for the design and the design selected was really only a rough sketch. The shells of the competition entry were originally of undefined geometry, but early in the design process the “shells” were perceived as a series of parabolas supported by precast concrete ribs. However, engineers were unable to find an acceptable solution to constructing them.

From 1957 to 1963 the design team went through at least twelve iterations of the form of the shells trying to find an economically acceptable form (including schemes with parabolas, circular ribs and ellipsoids) before a workable solution was completed. Utzon came up with an idea of making all the shells of uniform curvature throughout in both directions which was called a eureka moment.

The idea was that the shells were developed according to a spherical geometry providing a common denominator, the same spherical surface to deal with, with a similar curvature throughout. This was an elegant solution to a construction, which would otherwise have had to be done with a large amount of scaffolding and shuttering, both for the interior and exterior shape of the shells. Now the shells could be sub-divided into ribs, which again could be divided into smaller elements, which could be cast within formwork representing the largest rib-entity. Thus it was possible to pre-cast the concrete-shells in smaller pieces and assemble these pieces on location. Because of the simple and consistent mathematical principles that were applied to the design, construction was both possible and much easier and simpler than it would have been if they had continued with the original parabolic concepts.

Software architecture also benefits from simplicity of design. A simple, uniform design reduces development time, improves maintainability, and makes modifications quicker and easier.

Often developers and software architects think they have an “elegant” design because they have tried to design very generically and/or very object-oriented, used a lot of open software components, and/or tried to plan for yet undefined requirements. But often the result is software that is much more complicated and bulky than needed. Over-designed, bulky software is costly to develop and maintain.

How can you tell if you truly have a good design or not? Here are the five keys to good software design:

1. Is there a simpler approach? In practice, the simplest approach is always the best. This goes against some software architect’s instincts when they feel they need to address unspecified requirements, but if the requirements are not stated yet, second guessing, if it adds complexity, should be avoided. If there are implementation strategies that are smart and brainy but overly complex, scrap those also. Keep it simple.
2. Is it customer-focused? Often design trade-offs are made that make the developer’s life easier but impact the customer negatively. If there is no benefit for the customer, the code should be removed. Less code is always better. (This does not include features that improve maintainability or delivery since they will affect the customer positively. But does include features or technology choices or functions that only make the life of the developer easier).
3. Is it designed for the expected user base? Often developers expect users to be as technically savvy or computer-adept as they are and inadvertently implement software that is not accepted by their user base. This was much of the cause of the downfall of Seibel – what the software did was great. The companies that implemented it though just couldn’t get their sales users to use it regularly. Hence the value of capturing important sales data was not realized. This is particularly true for software that users will need to pick up and use without the benefit of formal training classes. Or for users who don’t use the software very often but need to be able to just sign on and quickly get their job done. Or for users who have other limitations. Remember the old adage “Know your users” and take it to heart.
4. Was performance considered? From top to bottom, software design should always consider the end performance. Performance should be a factor in basic architecture principles as well as 3^rd party tool selection. Nothing impacts usability more than bad performance. Except bugs.
5. Is it reliable, maintainable, supportable? Quality: Clean, simple software tends to be more reliable because there’s less that can go wrong. In the software industry, often there’s complacency about bugs – some people think software always has bugs. Typically though bugs are a result of overly complex design, large/bulky architectures, which result in not enough test time. Simple, clean designs take less time to develop and less time to test. Installable/Upgradable: Especially for applications that need to be installed at a client site, the initial installation and ongoing conversions to the latest releases need to be quick and easy. Desktop software is often quite good at automatic installation and updates; but surprisingly enterprise application software typically needs to be hand-crafted and customized on-site. And each conversion to a newer release can cost companies millions of dollars. There is no real reason why enterprise application software should not be easily installed and upgraded. No customer-focused reason anyway. Although vendors do make more Services and Consulting money that way. Reliable: Most software nowadays, especially enterprise software, quickly becomes mission critical and companies who rely on it need it up and running 24 x 7. That means it must have high quality, be quickly upgradable, and be scalable to meet a company’s growing needs.

Good design separates clean, customer-acceptable software from gorilla software. Why is good software so hard to develop? Companies delivering clean, customer-focused software may not make millions in services fees, but some day (hopefully) customers will start pushing back on the software gorillas who charge millions for every major upgrade. When that happens, companies who know how to develop clean, simple software will be in high demand.

History of enterprise software according to Jan:

• 1970s – Large companies develop their own internal Manufacturing Resource Planning and Finance systems to meet their specific needs. Because these are one-off projects, the cost to continue to address new requirements is costly; many systems become out-of-date and/or costly to maintain.
• 1980’s – Software vendors begin delivering MRP and Finance solutions and some Legacy (internally built) systems are replaced.
• 1990’s – Software vendors combine various application solutions (MRP, Finance, HR, etc.) into one Enterprise Resource Planning (ERP) software package – one size fits all – and more Legacy systems are replaced. The ERP solutions try to address all automation for every industry with a single software offering. Thus the software requires huge customization efforts to meet each company’s needs; installation and upgrades costs increase. Specialized “Systems/Consulting” companies are formed solely for the purpose of installing, customizing, and upgrading the large platform software.
• 2000’s – Software vendors consolidate into a few mammoth gorilla vendors. Large software infrastructure layers are developed to integrate all of the various application pieces from the acquired companies into one single “platform”. Systems became even more complex; software costs for installation and maintenance continue to rise. A few smaller vertical-based vendors still provide clean simple software but competition with the gorillas is fierce. CIOs are convinced by the gorilla software vendors that enterprise software needs to be big and needs to sit on monolithic platforms in order to “integrate” and be “enterprise-worthy”. Yet few, if any, CIOs are able to realize the promise of easy integration using the big monolithic platforms, even if they stay with a single vendor. Implementations and upgrades take years and millions of dollars to complete.
• 2010’s – Companies reject the big vendor approaches. They refuse to pay millions of dollars for each installation and upgrade. Clean, simple software is demanded. The software industry evolves to meet the need.

All agreed that design documentation maintenance is an unattainable goal. Some were engineers from a big major networking company, one from a mid-sized software company.

But the advantages of having a real “As Built” spec seem so obvious. A spec that is always updated before code changes are made, that is used by QA for testing and used by Tech Support for customer support and questions, a spec that unquestionably contains the use case scenarios and business algorithms implemented by the code. The advantages of having such a spec is so key to producing clean, quality code and so necessary for clear communications between the developers and the customer advocates (Product Marketing, Tech Support) that it seems to me an obvious requirement for effective software.

Yet these software professionals were in agreement that maintaining such a spec is not feasible. Perhaps I shouldn’t have been surprised. When interviewing candidates recently for a VP of Engineering position, I repeatedly found each candidate had a similar story – whether from a small start-up, a major application vendor, or somewhere in-between – each said they had never found a way to successfully document and track requirements to design to code. It wasn’t feasible, each said. Plus others I knew from a mid-sized software application company had same opinion. Product Marketing creates the Marketing Requirements Document in Microsoft Word. Engineering takes that and creates the design and then codes. At the end of the cycle, although the PM team attempts to maintain the MRD in-sync with the code, they say it isn’t ever really possible. Plus because some MRD documents describe enhancements to existing modules, they are “change” documents, and after a few releases there was no complete document defining the complete feature. One solution companies have tried is to assign the task of writing an “As Built” document to the Technical Documentation team after the code is released. Seems like a good idea? It would only be valid if the document were thoroughly tested by QA but that would require double-testing so is never done. Hence it’s only the tech writer’s best guess at specifying what the code is actually doing.

Yet I still thought these companies were anomalies. Even though, my friend and consulting partner, Anita continually encounters the same feedback from the students in her UC Santa Cruz training courses on requirements management, it seemed that these companies must not represent the majority. Surely most companies must have found the solution. Because the solution was not that hard to find.
But to hear again this weekend the wide-spread belief that maintaining design documentation isn’t viable me stop and take notice. I know the “Agile Software” community discusses the advantages of relatively sparse use of documents. But seems to me that the discussion is at the wrong level. By eschewing documentation we are losing a key component of an effective software process.
And what I’m advocating doesn’t need to take more time or effort. In fact, just the opposite. There is a level of documentation that can be easily maintained, aids every organization throughout the software company, and should be as much a part of a normal software development cycle as configuration management tools are. (Hopefully no one reading this blog would tell me they do not believe in checking software into a configuration management tool). Maintaining real, code-synchronous documentation is feasible and just requires the right tools and corresponding processes.

Yes – it’s an easy problem to solve. At Azerity, my company, we proved that having the right process and not only were feasible, the result was reduced headcount needed to design, develop, and maintain code. It was actually amazing at the size and complexity of software we were able to deliver and support with so few people. And a key component was the concept of complete, “as-built”, tested specs describing each application module. These specs became core to our company, our software bible, the key to our IP, and only the code itself was more revered and protected.

Our journey – how we got there. For the first few years as a start-up, we had effective processes for our size company because we had implemented, from day one, our Tracker tool (see DP Tracker tab) which was much more effective than open source tools like Bugzilla or their equivalents. For a team of less than ten with an application still small enough that key individuals could grasp the entirety of the product in their heads, we were able to implement and enhance the application effectively using only DP Tracker, CVS for code management, and MS Word for specs.

But then we got larger quickly as a company and the application grew. We doubled the engineering team. With plans to double the engineering staff once more we had a major expansion of new modules and enhancements being designed by our new Product Marketing team. We were becoming a real software company.

We hired a VP of Engineering and I took on the CTO position. Her first observation upon arriving was that using MS Word for specs wasn’t going to continue to be viable. And it was quickly apparent that she was right. We had a new Product Marketing team that were making spec changes, the developers were having difficulty tracking what changed from revision one, two, three of the Word docs. Some companies try to handle this by checking the Word documents into a code management system but that still doesn’t help the engineers clearly identify the delta between the spec and existing code.

Anita, our new VP, had recently completed a requirements tracking tool comparison at her prior company and Telelogic’s DOORs product (now owned by IBM) was the clear choice. We decided we didn’t need to re-evaluate tools and we purchased DOORs.

The beauty of the DOORs product is that it is similar to using Word so is easy to learn. But most importantly each requirement is automatically tagged with a unique ID that stays with the requirement even if you cut and paste and totally reorganizes the document which isn’t possible with Word or any tool that claims it can export and re-import to/from Word. Each requirement can also be tagged with other attribute columns. For example, we added a Tracker number attribute and other columns. Since DP Tracker was used for change tracking, workflow, developer and QA assignments, and ongoing developer/PM discussions, the Tracker number tied the spec changes to the developer’s work list and the rest of the software process all the way through to QA and deployment. Each time we made a spec revision in DOORs, the latest version was exported to centrally stored HTML files which all developers could access without having to own a DOORs license. Hence although requirements tracking tools are quite pricey, by only having to purchase licenses for the few key individuals that updated the specs, it was still an affordable tool. Tracker also linked to our code management system (CVS) so we had a complete, consistent tracking from specs to completed code to test. I’ve performed a lot of evaluations of similar tools over the years and unfortunately find that most lack some of the key features that made DOORs so effective. Hopefully IBM will continue to support and maintain DOORs. The IBM sales representatives seem to be pushing their Rational tool for software requirements tracking but it is missing key components we found so important.

There were two results of implemented process: (1) Because our tools were linked (DOORs, Tracker, and CVS) the result was a consistent flow from what Marketing was requesting in behalf of the customer, through design, code, test and delivery. In other words, the engineers actually built what the customer wanted and could do so with less time and energy. And (2) DOORs contained true “As Built” specs. QA tested against the DOORs specs as part of their standard testing and so the company was assured that what DOORs contained matched the actual code. Because the DOORs specs were accurate, other teams (Technical Support, Professional Services, Sales) could quickly access (via the HTML exported pages) exactly what the code did or did not do.

The DOORs specs were not design docs in the true sense of the word. No UML or lower-level implementation concepts. DOORs documented the user scenarios (screen shots and descriptive text), business functions, as well as lower-level information (business algorithms, policies enforced, and even database schema). They contained everything needed to communicate organization-wide what the software was supposed to do and did do.

And this approach simplified everything. Engineers were happy because they had clear direction about what to change when. And if a customer reported a “bug”, there was an easy way to tell if it was really a “bug” (developer mistake) or new, previously unidentified need because if it was in DOORs but the code didn’t work that way, it was a bug. Otherwise, not a bug. Code didn’t change without the spec being updated or, if the spec was found to be missing key information, the specs were always updated and tested so always both items, spec and code, were always in sync. The specs were a living, breathing documents. And this streamlined process and total consistency throughout the software life cycle has been proven to improve quality, reduce the delivery time, and enable technical support to provide better customer support with fewer people. Win-win-win.

Contact Jan or Anita if your company does not have a low-cost, high quality software process including a complete set of “as built” specifications for your code. We can help implement the Azerity process and tools at your company to help you sail smoothly through your software development cycles!

But sometimes the smoke is hard to see even when there’s fire a brewing. Maybe the smoke is just a wisp or the fire is smoldering under wet ashes and everyone just thinks it has been extinguished.

It’s similar with software management. How can you be sure you aren’t missing the signs of your project going astray? Problems brewing under the surface.

The best way is to focus on your customers and how they perceive your company and your product. The old adage “The customer is always right.” is a good barometer for gauging how your company and your product are doing. Is there smoke spewing and you are not paying attention or is it smoldering and hidden but underneath the surface?

Almost every company “says” they are focusing on the customer and usually decisions are being made in what is perceived to be the best interest of the customer. But often we think we are working for the customer’s benefit but we’re missing some key points. Are we focusing on only one aspect of what they want yet not delivering what they really need?

For example, how often have you heard a project team say “The customer’s schedule for delivery is on July 7^th so we had to freeze the design last week to meet their schedule.” But is the design that was frozen going to meet their needs? Is the code that is being delivered going to best solve their problem? What if the design team was stymied with how to meet the requirements. Should the team just go ahead freeze the design, code and then deliver just to meet the schedule? Where is the trade-off between quality and schedule? Maybe delivering whatever we can in the required timeframe avoids the big explosion, the blow-up that would occur if the project manager had to tell the client that they can’t meet their schedules. But it doesn’t change the fact that there’s smoldering embers underneath the ashes and eventually when the wind blows (when the customer starts doing their final testing) those smoldering embers will erupt in flames. When the software is delivered but it doesn’t meet the requirements, there will be fire. The best managers will be willing to take the heat and tell the customer up-front if the team can’t meet the schedule. Of course, the underlying problem – why the team thought they could meet the schedule but then missed their target – needs to be examined and rectified so the problem doesn’t happen again. But if the team typically estimates well and is able to perform, but for one project there is a snag, then the customer isn’t served by focusing only on one element of the delivery, the schedule. Quality always has to come first. In this case, “quality” means delivering the software which meets the agreed-upon requirements, requirements that truly meet the need from the customer’s perspective.

Project Managers need to continually scan the horizon for smoke that indicates a fire about to erupt. A project manager that declares milestones complete without actually completing the work is always a sure danger sign. Schedule versus quality is just one example but one that seems to occur far too often in real life.

There was a great big old house in Ashville the looked like it could have been a plantation or stately manor. It had a huge porch all the way around the house . The owners had turned it into a restaurant and the porch now had picnic tables set for visitors. We went there the first time with our 2-year old daughter and were seated at one of the picnic table overlooking pine trees. There were no menus but the table was already set with plates and dinnerware. Shortly a woman came to our table and said “Today we’re having chicken and pork. Would you care to stay for dinner?” Not sure what that meant, having expected a menu so everyone could order their choice, we wanted to find out what this Southern option was so agreed and soon large bowls of roasted chicken, pork, boiled potatoes, and black-eyed peas were brought to our table – Southern cooking, family style. I’d never had black-eyed peas before.

Years later I attended a software management lecture by a man from Tennessee who, with his very Southern accent, talked about the “fuzzy P’s”. I initially thought he was referring to those black-eyed peas from the South. But no. He was referring to the 3 P’s that drive a software project: People, Plan, and Product. “People” are the number of heads you can put on the project. And while you can’t gather 9 women and produce a baby in a month, there are some impacts that can be made if the right resources are allocated to the right schedules. “Plan” is the schedule – moving the schedule in or out is an obvious choice and one of the ways a manager an effect the end result. And “Product” refers to how much product (how many changes, bug fixes, enhancements) is included in that release or that service delivery to the customer. Remove some features, save some time.

The three “P”s can be adjusted to affect the end result. But that’s it. Those are the only viable axes in the three-dimensional world of software that can be controlled and still produce a good, product. If axis one doesn’t get shortened, the others will not be impacted. If a software schedule can’t be met, then either more people are needed or less changes / enhancements/ fixes can get into the delivery.

Usually CEOs want it all – they want the product with all the specified features in the timeframe they want it using only the resources that fit their budget. But if the three axes don’t align, something’s got to give. And it’s the software manager’s job to juggle the axes – more people here, less product there. But CEOs push back and too often software managers try to appease them and agree to accept the dictated schedule with the resources allocated and all the specified product features.

And there’s only one result – the hit is on quality. When there aren’t enough resources to do the job right, quality suffers. It isn’t always apparent to the CEO. Perhaps the team even thinks they are doing a good job by delivering the product and making the milestones. There’s a big party to celebrate the release, and everyone is congratulated. But it’s the customers that will be impacted when they encounter the bugs that ultimately will result.

And ultimately this approach will affect the bottom line. It’s another well-known software rule that bugs found by a customer are 1000 times more costly to fix than bugs found during the design phase. If a bug found during design (or at that point, an issue or problem) cost $1 to fix, if it isn’t found in design but rather during coding it will cost $10 to fix. If found during the QA cycle it costs $100 to fix. And the same issue found by the client costs $1000 to fix. Measure it. It’s a fact. Issues found by clients need to go back to the design, impact code, changes are likely to cause other issues, QA needs to be re-done. Manuals updated. Other clients notified. It’s a very expensive proposition. Not only that, it affects the customers’ perception of the company and it’s software.

So why isn’t quality the primary focus since it’s the most expensive error to make? It’s the fourth fuzzy P. “Perception.” As long as the CEO “perceives” that the product is going out regularly, that everything is on track, managers are rewarded and all’s well. Or seems to be. But letting quality slide is a slippery slope. If no one is tracking the overall quality metrics, quality can slide without anyone noticing until the product has degraded to the point the customers rebel. Take the Microsoft operating system years ago where the blue screen of death was the well-know scenario.

Bottom line – the trade-off should never be quality. Good software managers need to watch their P’s and their Q.

This was a special satellite – the largest ever launched at the Cape. With solar array panels that would unfurl to the size of a basketball court. A flexible antenna that would would spread 40 feet, large enough to provide satellite communications for the entire US.

But even more special was the fact that this satellite was, unlike any of the other satellites my husband’s company builds – communications satellites for various countries or for Intelsat, weather satellites for the weather service – this satellite was commissioned by a small start-up company. Only 50 people. All part owners of the company. And so they all came to watch the launch with their spouses and small children. Their entire company rested on a successful launch. And the riskiest part of a satellite launch is from the launch pad to orbit. Risk of the rocket exploding on the launch pad, an explosion as it is being hurled into space, or a failure during the separation stage. Satellites take 3 years to build. Even though insured, a replacement satellite would take at least 2 years to build. A big risk for a start-up ahead of the competition with new technology and leading-edge ideas.

And so it was, with breaths held in, that everyone watched from the balcony of the observation platform as the rocket’s engines began to spew billowing smoke and with a roar, the huge weight rose from the launch platform. The cheer was heard from the crowd and everyone hurried to the monitors to view the rocket perform through it’s roll and booster separation stages. Mission control provided ongoing updates of the status of the satellite – 5,000 miles above the earth, 10,000 miles until, 30 minutes later, it reached it’s destination 19,400 miles high over Australia where the satellite module performed it’s final separation from the rocket, free to use it’s own thrusters to raise to it’s final elevation and begin to unfurl it’s solar arrays. It would be several weeks until it was completely positioned with the antenna unfurled and ready to begin to transmit but the high-risk part was over and everyone could breath a sigh of relief. A successful launch! It was a thrilling event to attend.

One of the company’s Board of Directors said “I’ve been on the Board of many start-ups. But never in my life have I had the experience where so much rested on 30 minutes.”

But was he right? True, it was very apparent the risk and rewards of that 30 minute timeframe. But are other time periods, other moments of lesser importance? In Dan Millman’s “The Peaceful Warrior” books, Dan’s teacher Socrates, drives home the lesson that there are no ordinary moments. Socrates teaches to be aware of your every movement and to appreciate every task. That the more we are able to live in the moment, the more we get from our lives.

How does this apply to companies and managers? It’s surprising how often companies have no real direction or worse, no sense of urgency. Most companies think they have both yet an outsider can easily see that they are not moving forward but rather in a circle. March’s blog talks about the use of metrics to measure the real progress. But you can also recognize moving in a circle in other ways. How often have you been to meetings and realize that the same meeting was held six months or a year ago with the same resulting list of goals or same decision yet people walked out of the meeting and months later there was no action. Often we move along in a daze, without making progress towards the goal but not recognizing it, much activity but very little progress. Measuring progress with metrics is a way to tell how you’ve done. But to really be effective, one must be very focused on the small details, all of the pieces – each moment where a decision or lack of action can make the difference between success and failure. So when we think that it’s OK to just do the minimum required to meet a schedule, that as long as we deliver something on time, even though we know it has a minor quality problem here or a known issue there, we are saying those are the ordinary actions most companies do and they squeak by so why shouldn’t we? Why should we keep trying for perfection when we can get buy with less?

A 30-minute launch is extremely spectacular but let’s not forget that moments that seem ordinary can end up having a huge impact downstream. If we could recognize how special each moment is and act accordingly, wow. Wouldn’t that be spectacular.

In a company, torch bearers are needed in every organization. It’s easy to get in a rut of complatency, doing your job day after day. Often no one notices the slow deteriorization of quality or effectiveness.

Another way of saying it may simply be that no one is “watching the ship.” Some might argue “Isn’t that just a normal part of good management?” But to that I’d respond “Yes. But…”

Yes. It’s true that good managers continually monitor and measure performance. But after 30 years in the software business I can also say it’s common for even good managers to get focused on the wrong metrics. Or focused on fighting fires and the performance and process metrics go by the way-side. Or focused on following the company mantra and miss the signs that indicate real, underlying trouble.

March’s blog talked about the use of metrics to identify and quantify changes in effectiveness over time. But often the message that the metrics are elucidating go unnoticed unless people are ready and willing to carry the torch to help the decision makers and top-level management see the light.

Sometimes in a software company, all organizations are hard at work but something is amiss. In one software company, the technical support team was feeling that the customer’s needs weren’t getting addressed yet all of the product organizations were working hard, producing new releases with client-requested enhancements, and regularly issuing standard bug fix maintenance releases. All of the orgs felt they were busy and overworked but that the product and quality were on track. But by using metrics, they were able to assess the real status.

Metrics were evaluated about the number of customer calls currently being reported that were product bugs or other product issues versus the number one year prior and two years prior. The metrics included turn-around time to get the issue resolved.

What was clear from the metrics was that the number of bug reports had been steadily increasing as new clients buying and installing the software and existing clients were steadily upgrading to the newer releases. In parallel, several new projects were underway, stretching the bandwidth of the product marketing, development and QA orgs. So instead of trying to quickly fix all newly reported issues as they came in, which had been the process in prior years, in order to reduce workload on the developers and QA, fixes were being pushed out to maintenance releases two, three, or more months in the future instead of the next planned release. As a result, more clients were finding related product issues and more issues were being escalated. So to appease the clients who complained the loudest and wouldn’t wait for the future releases, the clients were sent one-off class files, tested only by the support organization instead of QA. If multiple clients needed the change in different releases, the developers zipped up sets of fixes. Then confusion ensued about which client had what file and instead of easing the load, this new degraded process was actually increasing the amount of work due to more call and more one-off fixes. And as a results, the overall product quality was impacted, causing more client frustration. When compared with prior years where bugs were immediately categorized and important issues quickly fixed, now there were too many fire drills and much confusion.

Metrics in this case uncovered both the negative quality trend and the underlying cause. But there is a right way and a wrong way to use metrics. A company can recognize metrics used in the wrong way when employee behavior is effected in non-useful ways. For example, one company used metrics to measure their Technical Support response time and rewarded the techs for maintaining 90 percent first-customer-contact turn-around time in less than four hours. The TS metrics looked great but in reality what the techs were doing was that when they received an automated call from a client, they would place their return call during the lunch hour or just after the company closed, raising the probability that they would be able to simply leave a voice message thereby responding to the call within 4 hours but without having to spend time discussing the call or resolving the problem which could tie them up and make them miss another client’s 4-hour call window. As a result, clients were not talking to a human for one, two days or up to a week and were playing “telephone tag” and getting frustrated.

In another company, a percentage of each developers merit plan was based on low bug count. But often issues reported by users as “bugs” were in reality items that were never spec’d or were spec’d incorrectly. So a lot of conflict resulted, arguments between the development org and support arose (“It is a bug.” “No, it isn’t a bug.”) Team members became opponents which created organizational silos and mistrust. Once the underlying issue was realized, the process was changed and a new Tracker category was created separate from “bug” or “enhancement” to denote a design flaw or spec bug. This allowed the Technical Support team to push that the issue was perceived to be a bug in the client’s eyes and thus get the problem resolved in a maintenance release rather than wait for the yearly enhancement releases.

But correctly removed the “blame” from the development organization since the issue wasn’t caused by a coding or process issue like a real bug would be and the correct metric was then being used to measure developer performance. The finger-pointing and arguments ceased, silo walls came down, and the product organizations coalesced into a supportive, cohesive team.

It’s easy to maintain status quo – to march along without noticing the slow and gradual deterioration of quality and effective processes. But by stepping back periodically and reviewing key metrics, teams can make sure they are working effectively and efficiently.

PS: Make sure you have measurable metrics – use Tracker to track Calls, Bugs, Enhancement requests and more. For at-your-fingertips metrics for future use.

In January it rained. Referring to both the weather and the work. Good for the pocketbook but not good for my fledgling Duck Pond Software and my newly proclaimed entrepreneurial vision of the new company of the 2000s. In other words, I spent almost full time contracting back to my prior company Model N. I did most of it working from home, so it wasn’t like I gave in totally to the corporate structure. And it was fun. But still . . .

The first half of January was more typical for me – part-time Model N work (split between getting my briefings ready to present at Rainmaker, the Model N user conference to be held in February in Phoenix, and on designing a new Rebates module) and part-time moving Duck Pond Software ahead with potential partnerships and customers. Then mid January I got a call from three Model N managers all excited and panicky because of a potential hot new customer deal and marketing arrangement if they could get their software integrated with SalesForce. com tout de suite. This meant an immediate full-time diversion in order to get a live demo up and running in a couple of weeks. The CEO wanted to make an announcement at Rainmaker about a Model N/SalesForce partnership. It was, to our CEO, one of the biggest announcements Model N had ever made. Besides diverting me, they said they’d assign Freeman full-time. That’s what made it fun.

Freeman and I have worked together for about 15 years through four companies. I hired him initially right out of college. He proved himself quickly, becoming the software architect at Azerity. He’s a brilliant and creative engineer but at the same time practical, down-to-earth and loads of fun. He was probably the first engineer who worked for me who was the age of my daughter. But rather than making me feel old, his wit and liveliness always kept our work fresh and fun. Plus he lives and works in San Diego (Model N’s one remote software engineer besides the offshore team in India) so my working from home wouldn’t be a problem on this project at all since he would be working from his home too.

Long story short, we spent two hectic weeks but delivered the demo, got kudos from everyone, and the CEO had the joint announcement for Rainmaker. And the January paycheck was also very sweet. But in the end, it’s just a paycheck received while building on another entrepreneur’s dream versus building momentum towards my own dream.

It was the last hurrah for Freeman and I working together which made it a bitter-sweet success. Freeman joined a start-up locally in San Diego at the end of our project. He’s going for the entrepreneur dream getting in as the third member of a team not even officially a company yet. However, I wouldn’t be surprised if we work together again some day. . That’s the cool thing about the new companies of the 2000s. It’s like the website LinkedIn and other networking sites that are springing up. People in this century want to be building their own dreams, not working for big corporations where there’s a single entrepreneur who’s the only one who ever makes it big. We all want it our own way

We want to make our own rain.

I’ve worked in the big aerospace and defense software world, been a software exec in various commercial software companies, done the “start-up” bit. I’ve proven that the “80′s” development practices and procedures can be leveraged and changed to work for the 90′s and 2000′s. I might say (humbly I hope) that I always was a great software manager – my reputation was on-time delivery, teams that were motivated, all that good stuff. At my own start-up, Azerity, we produced a product that competed with the big gorillas (SAP, Oracle) and won every time. I’m not stretching now – that software was used by major corporations for mission critical tasks (quoting, pricing) and was reliable (never crashed – really), scalable (30,000 users worldwide), and high performance (just what you want from a web-based system – click click click – screen after screen snap, snap, snap). And it didn’t cost the clients millions to install and millions more to upgrade (semiconductor companies may be big but they are very, very cheap!) When we were bought by a bigger company, within 9 months, the acquirers made more in software sales of our product than they paid to buy the company.

So I went back to the company that acquired Azerity and negotiated the rights to relicense the tool we’d built, SD Tracker.

So now the question is this: Go back as a VP Engineering at an existing company and use SD Tracker and processes and lessons learned and do it all again? Take SD Tracker and start a new start-up going after VC funding and that whole gig? Golf every day? Or some combination of all of the above.

By the way – the other change last year was moving out of Silicon Valley to Discovery Bay – “Live where you play in Discovery Bay” is our city’s official tagline. (Or an alternate is “A small drinking town with a boating problem.”) Both fit. Wonderful place to live – BUT, a 2 hour drive to Silicon Valley where the companies and action are.

We built our house on Drakes Drive, have the Delta (Sacramento River) as our back yard. Wake to the sounds of ducks, geese, and seagulls outside our bedroom window, golf on a lush course abounding with lakes (i.e., duck ponds). Seeing a theme here? So I named my fledgling company “Duck Pond Software”. At a minimum it’s my DBA for consulting back to my prior company for a while. But … maybe more…