Skip to main content

You Can Pay Me Now, Or…

If you've spent even the smallest amount of time talking to me about software development, you know that I am a big time "You can pay me now, or you can pay me later" kinda guy. With Software Quality, if you have not paid in advance, you will certainly pay later -- and the price will be much higher than if you had just paid up-front.

I'm one of those types that puts significant value on the Quality Assurance department of any software development shop. So, I appreciated seeing the post at OnStartups: Business Geeks: Automated Software Testing as Competitive Advantage. The key here is "Automated". There's really no way to build a scalable software business if you do not invest in good software engineering practices, combined with automated testing.

Most startups (and, heck, even many big, established companies) do a crappy job with their Software Quality Assurance programs. Why is that?

  • Most CEOs and VPs of Engineering do not understand its importance. Oh, sure. They all say that "Quality is Job 1" or whatever, but when push comes to shove and the product "needs" to be shipped, quality is the first thing that is sacrificed. Executives feel that they can always patch the product later. That's a fine approach, it will just cost you a lot more.

  • It's very hard to build a QA group with rock-star programmers. Often times, junior engineers will be hired into the QA department. They will grow there, but the first chance they get to create "product" code, they will try to transfer out of the company or, worse, quit and move on to a different company. Organizations need to reward QA programmers with equal career paths as their code-writing counterparts.

  • QA is not factored into the early planning of a software product release. Software teams will spend tons of time fighting over requirements, scope, features, modules, partitioning the teams, outsourcing, private APIs, public APIs, usability, configuration files, installation, upgrade, etc. Frequently, however, the automated test suite is not given its proper attention. If you miss it while planning, you will miss it while executing. While you are doing your product design, you need to be doing your test design.

  • Most organizations have no structured software development lifecycle. If you don't know when a product can transition from Alpha to Beta to GA, or when it's time to release a patch vs a hot-fix, or when to release a dot-release vs a dot-dot release, or when its time to do a major release, or the criteria by which you EOL a product -- then how do you know when its time to test? And, if you haven't invested in "Automated" tests, then you will be paying a pretty significant price each time you send something out to a customer.

  • The testing cycle is often the last thing before product ship. Most companies treat testing as something that happens as the final "certification" that allows them to release the product to customers. That's very bad. Testing needs to be the first thing that is done. The only way you know you are "done" is if the test suite passes.


At my last company, Cassatt, we have a rock-star group of software developers and QA engineers. We instituted what is referred to in the Agile software arena as a "Test First" software philosophy. How does that work? The developers specify the unit tests at the same time that they specify the design and the interfaces. They code the tests first, then code the module. When the tests all pass, you know you are done. This gives the QA department the ability to look beyond the unit tests and focus on multi-unit, simulation, stress, code-coverage, and GUI tests. It requires rigor and structure, and a management team that believes in the Pay Me Now form of software development.

You can Pay Me Now.

Tags: , , , , , ,

Comments

  1. Excellent post...I'm not that knowledgeable yet about software development yet it would seem to be a lot more satisfying to those involved to have a series of small wins that builds to a clean, functional whole.

    Is the "Test First" approach widely used?

    It seems more common to have the QA/testing function as the end point of the development cycle.

    My business plan shows salary lines for "junior engineers" in QA...hum...may rethink that...

    ReplyDelete
  2. Wonderful Brian:

    SaaS is the preferred approach...fortunately the current market leader in my space has utilized this structure for a number of firms that they provide the service to...so I wouldn't have to sell a new method.

    I really like and appreciate your comments on QA. Especially the idea that the QA leader is a peer to others on the development team. And that method and process can evolve given the strengths of those involved. Not being a developer myself I'm not wedded to any methodology but I do believe that a system should be in place.

    Many thanks, Cate

    ReplyDelete

Post a Comment

Popular posts from this blog

Kernel-based Virtual Machine hits Linux

Many congratulations to my good friend Moshe Bar and his team over at (stealth-mode startup) Qumranet . Techworld reports that the KVM (Kernel-based Virtual Machine) project has been accepted into the 2.6.20 version of the Linux kernel distribution. KVM is an Open Source kernel driver that basically allows a Linux kernel to host virtual machines, as plain old Linux processes, that can run Linux or Windows (or other x86-based operating systems). It runs only on hardware that support Intel's VT instruction set (which is fine) and will soon support the AMD-V instruction set as well. This is cool for a number of reasons. It's Open Source, released under the GPL. It basically turns the Linux that we all know and love into a "hypervisor". Linux-as-hypervisor makes sense because Linux already knows how to manage devices, memory, processes, multi-cores, etc. VMware ESX is, essentially, a "hypervisor" - a small kernel, built on Linux as it turns out, that

Bill Coleman Joins 3tera Advisory Board

I think this move surprised a number of people, since Bill recently wrapped up Cassatt Corproation, getting the technology and people  acquired by Computer Associates . However, I was not surprised at all. The announcement, via  3tera Welcomes Bill Coleman : You may or may not have seen the recent press realease.  Bill Coleman, IT/Silicon Valley luminary, Founder and CEO of BEA Systems, has joined 3Tera’s Advisory Board. Yes, this alone is a great testimonial to what we have accomplished in our field.  Getting dignitaries such as Bill does not come easy.  But here’s the best part - this has a lot more than just marquee value and I doubt that Bill would have joined us if that was the case.  Bill, especially since his most recent stint as Founder and CEO of Cassatt Systems, is an extremely knowledgeable visionary in the area of utility and Cloud Computing; and, data center automation. So, Bill will be extremely valuable, reviewing and tweaking both our business plans and techno

Big In Japan Open Sources Their Ruby On Rails Tools

The kind folks over at Big In Japan have graciously decided to Open Source the code they used to build their demo web sites . It's all Ruby on Rails code, and it's being released with a GPL license. The code trees being made available include: elfURL ~ URL Shortner FeedVault ~ OPML file storage FrankenFeed ~ RSS feed merger InstantFeed ~ RSS feeds via email QwikPing ~ Ping Server SocialMail ~ RSS via email Very cool. I just love the Open Source community . I have actually been writing some code of late, and it's great to have some reference code to check out. Not sure if I'm going to go with Ruby on Rails yet, however. And, for the record. I have no idea if this is big in Japan. Tags: Open Source , GPL , Ruby On Rails , Big In Japan , Brian Berliner , brianberliner