“It Starts with an Idea” – Available on Amazon

“It Starts with an Idea” is finally published and available on Amazon – Click here.

FrontCover

Read about the adventure of a start-up in Silicon Valley. The book interlaces the story of the start-up Intelic (renamed “Azerity” in 2001) with stories from prior jobs, valuable lessons learned. The book reveals how Intelic created a dedicated and enthusiastic team – a team that worked hard and had fun – and a great product.

Almost Ready to Publish!

Now that we’ve finalized on a book title and sub-title that ties in, the final draft proof is on its way in the mail. The title and subtitle are: “It Starts with an Idea” – How a little software company competed against the big software gorillas by turning an idea into practical software.

FrontCover BackCover

Our friend, Pete, came up with the title, which was actually one of the early chapter titles. Since the book is about a start-up, it made sense to use that as the title. I like it.

One final review then it goes to Amazon to publish a print and Kindle version. Hope you like it!

Naming a Book is Hard

OK – No one likes either of my first two book name ideas: “Gorilla Warfare” (sounds like a story about combat if you don’t know how to spell, or an issue in the jungle with real gorillas if you do know how to spell) or “Practical Software” (sounds like a boring technical manual). People suggest that since it is such a fun read, it should have a title that draws people to read it other than just software geeks. Something catchy that would cause people to download it from Kindle.

The byline is “How a little company competed against the big software gorillas by building practical software” (that is working well), the book talks inside about competing with the big software gorillas, and so the cover has a gorilla on the front, little chimp (our company) on the back.

New suggestions currently are:

  • “It Starts with an Idea” – that’s actually one of the early chapter titles.
  • “Safari into the Software Jungle” – unless it’s too long.
  • “Software Safari” – if the above is too long. But the one above sounds more fun to me.

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!

Holidays
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