Class of ’67

“Mimi,” said my granddaughter, Serenity (she calls me Mimi), “tell me a story about when you were growing up.”

That was a constant request from our little Sassy (our nickname for Serenity).

I’d finished writing my book about my software start-up, It Starts with an Idea, and had learned how to use Amazon’s self-publishing website, http://www.createSpace.com, and thought to myself, “Instead of telling her stories all the time, I should write them down so she has them forever.”

I mean, I’m not getting any younger and you know what say, “Memory is the second thing to go.”
“What’s the first?” you ask.
“I forget.”

I started reflecting back on my childhood and growing up in Utah. As a young child, I lived in a very homogenous (aka white), Mormon neighborhood. All of the kids in my elementary school were white and Mormon, except Joanne who was Catholic and the kids teased her about that. That’s not exactly right. I had a good friend who was Japanese but in general, white and the same. Until junior high, that is.

Our junior high was right on the board of the East Side of Salt Lake (where we lived) and the West Side (across the tracks). Arriving at junior high was quite an eye-opener. I remembered one day we even had a rumble – quite “West Side Story”-ish. I wanted to do more than write stories, I wanted to create the atmosphere from that time. Growing up in the ’50s; the vibrancy, how we lived and played. So I wrote it more like a novel – starting out in the summer before I headed off to school at junior high the first time.

So my story starts out when I’m awoken from the drum beat of the South High Pep Club marching in the park near our house:

I awoke at 7 a.m. to the sound of the drums. Boom, ba-da boom, ba-da, boo-boo-boo-boom. It was the beat of the South High Pep Club, who would be practicing at Liberty Park every morning for the next two weeks. The park was very near to our house – close enough that the drum beat echoed through my bedroom’s open window.

“Argh,” I thought as I tried to pull the covers over my head. My sister Kathy, five years older than me and soon a senior at South High, would already be at the park, going through the routine with the other Pep Club girls. But for me, it was supposed to be a lazy summer morning, and I had planned to sleep in.

I would be starting junior high soon, and needed my sleep. We had only two weeks left until school started, and I hadn’t wanted to be woken up early.

Then I heard the pans crashing in the kitchen and knew Mom was making her oatmeal. She always ended up making a huge noise in the kitchen when she was trying to get her small oatmeal pan out from under the bigger pans for her early morning breakfast before going to work.

I dragged myself out of bed and padded into the kitchen.

“Really, Mom?” I asked. “Can’t someone sleep in around here?”

“Now that you’re up,” she said brightly, “make my coffee. OK? I need to get to work.”

Then what to name it. My first choice was “On South High!” the opening words from our high school song. But my husband and others who hadn’t attended South didn’t “get it.” So then I picked my high school graduating class, “Class of ’67”.

frontCover

I used pictures from our yearbook and our school colors, blue and white on the cover.

As luck would have it, I published it shortly before our South High Class of ’67 had its 50th Reunion. Needless to say, it was a big hit at the reunion (I took extra copies). Even my sister’s friends bought it (and she was five years ahead of me in school). They all said how it reminded them of their school years and what a fun read it was.

On South High!

That was so exciting. I think I need to write more books!

“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