Get rid of manual quality control

March 29, 2010 – 5:55 pm

After reading recent Eric Ries piece in HBR, one thought was bouncing my head…

What are such rules for software development service companies, like mine 42 Coffee Cups, that does Python, Django web development?

Some things in Eric’s article resonate quite closely to me. For example, when a stupid bug creeps into the code we deliver to our customers for review, at least half of time I’m being asked - aren’t your QC people watching it?

I had difficult time answering this, because my gut feeling from 20yr of software development is that dedicated QC slows things down while hardly compensating with increased quality.

You know, if debugging is the process that removes bugs from a code, then programming must be an activity that implants the bugs there.. :)

In my reality, when this bug is drilled down to find the cause, it’s almost always something like

  • the particular piece of code wasn’t covered by unit tests
  • whoever integrated the code didn’t run the tests before shipping (yup, it happens occasionally - we’re all humans)
  • whoever integrated, hasn’t bothered to eye-check the result and html, being clean, gives awful UI experience
  • there was a deadly misunderstanding between customer and developer

Each and every item on the list could be fixed by either

  • automating more work
  • adding more automated checks, like running CI tests on every checkin or measuring the test coverage
  • delivering to customer faster and ask for his feedback

During early stages or if done wrong, this gives awful results - a customer has to spend a day just listing defects :(

Yet…

Isn’t a reliably shorter round-trip time (time from a feature request submitted and the code shipped to you) and solid process of “making errors only once” much better than have to wait an additional day (on average) for QC review, pay for its costs and still have errors shipped sometimes?

42 Coffee Cups still have a long way to walk to achieve the ideal sanity, yet I believe this is a way to go

What do you think?

How to convince boss to use TDD

March 25, 2010 – 11:25 am

Some time ago I was contacted to find arguments to introduce Test Driven Development into a company process. Or, at least, start doing some automated tests.

Quick chat revealed that, while doing iterative development and having dedicated QC team, during the 2 year age of the product, the pace of development is slowing down and with each next release it becomes more difficult to get it out of the door. Some defects even creep into production.

If that would be a service company, like ours 42 Coffee Cups, I’d suggest to do a small pilot project using TDD and compare metrics. Product company, unless they want to run a controlled experiment (or a side project) are left only with comparison to foreign projects.

As we’ve dug deeper, it became obvious that team lead, who contacted me, made no efforts to baseline team performance.

They do use JIRA, do weekly iterations, but yet, it’s used just as a sophisticated todo list.

Since team lead guess was that pace is directly affected by bug count and this is related to the codebase size, the obvious metric would be the number of defects found (weekly) compared to SLOC count. Hypothesis to be proved: the larger amount of code gets - more defects per KSLOC pop up. While it is obvious to the lead, it is far from obvious for budget holders.

Their arguments:

  • we have already large codebase, no chance to cover it with tests in realistic timeframe and budget
  • tests are hard to support
  • the effect of tests is not obvious
  • tests double development time

From that point on, it was obvious how to advocate for automated tests:

  • we may start with tests for just new code and bugfixes
  • that’s not true (and provide proof references)
  • … and here is the effect of tests absence! - and show the graph (defect per KSLOC) vs KSLOC total
  • tests do not double the development time and their absence cost real money - and again show the graph that shows defect creep

Final suggestion was to introduce test in guerrilla fashion - just start writing unit tests for defect fixes.

Automated django deployment

March 19, 2010 – 5:02 pm

We at 42 Coffee Cups do alot of django projects. Additionally I care about developer staffing, which means one more test project per candidate.

That totals to about 20 commercial and internal projects any time and 10-15 test projects.

That’s not a trivial amount and, given we deploy projects onto testing/staging server after each feature integration, the time spent in deployment is rather big. Last informal survey showed that PM doing the integration work, spends 10% to 50% of his time reviewing and deploying updates!

Of course, we automated it to the point of executing make deploy but I’ve always wondered of other options. Especially given the virtues of Continuous Deployment we would love to enjoy on every project.

Right now under the hood of make deploy we have scripts that

  • tag a version in a git repository
  • create a version archive
  • upload it to server
  • unpack and play with symlinks to mark this version current

What’s missing is:

  • automated db migration
  • automated server restart
  • fallback if something goes wrong
  • automated creation and management of versioned environment

So I’ve researched the area a bit and come down to the following DIY solutions:

Am I missing something, trendy or not?

Perhaps there are commercial (SaaS?) solutions available that I’ve not been able to dig out?

What’s your experience in this regard?

Epiphany - Customer Discovery steps

February 2, 2010 – 2:44 am

After having bunch of discussions at #sctest, #pykyiv and privately, I decided to post a distilled version of Customer Discovery steps by The Four Steps to the Epiphany by Steven Blank

Here it is. Just execute it:

Customer Discovery

State Hypotheses

  • Product Hypothesis
    • features
    • benefits
    • intellectual property
    • dependency analysis
    • product delivery schedule
    • total cost of ownership/adoption
  • Customer & Problem Hypothesis
    • types of customers
    • customer problems
    • a day in the life of your customers
    • organizational map and customer influence map
    • ROI justification
    • minimum feature set
  • Distribution & Pricing Hypothesis
  • Demand Creation Hypothesis
    • creating customer demand
    • influencers
  • Market Type Hypothesis
    • market type
    • market map (p. 56)
  • Competitive Hypothesis

Test “Problem” Hypothesis

  • Friendly First Contacts
    • list of 50 potential customers
    • get a referral
    • create a reference story
    • get 5-10 meetings
  • “Problem” Presentation
  • Customer Understanding
  • Market Knowledge

Test “Product” Hypothesis

  • First Reality Check
  • “Product” Presentation
  • Yet More Customer Visits
  • Second Reality Check
  • 1st Advisory Board

Verify

  • Verify the Problem
  • Verify the Product
  • Verify the Business Model
  • Iterate or Exit

Computational chemistry in Python - action plan

November 20, 2009 – 12:37 am

My favourite scripting language is Python and there are quite few interesting projects done:

  • PyMol - molecular visualization system on an open source foundation
  • MMTK is an Open Source program library for molecular simulation applications.
  • PyQuante is an open-source suite of programs for developing quantum chemistry methods.
  • cclib is an open source library, written in Python, for parsing and interpreting the results of computational chemistry packages.

PyQuante and MMTK are most suitable for the start of method framework.

Action plan:

  1. Bootstrap PyQuante. It works out of the box, but some of its tests do not pass - have to check this out.
  2. Do the same for MMTK.
  3. Implement at least some gradients and force constants functionality for PyQuante and make sure geometry of simple molecules optimize to something reasonable
  4. Dissect popular and not-so-popular QCh software packages to work within the framework above.
  5. Compile a basis set and a control set of molecules to control and optimize precision of different modeling methods
  6. Sum up, review and work out a new plan.

Time for computational chemistry

November 20, 2009 – 12:05 am

Lately there wasn’t much things to write about.

When you scale your business, there are plenty of lessons and observations. But theren’t that much you’d really like to tell the world about, and even less you can because of various NDA and confidentiality issues.

Nevertheless, looks finally (knock-knock-knock) 42 Coffee Cups can run successfuly without my 24×7 attention and I can devote my time to other interests that waited for too long.

Once of them is computational chemistry.

I’ve done some scientific work using computational chemistry modeling in 1990-1997 and still believe that it is the necessary element of nearly every future technology in health, energy, chemistry, IT, food, etc for the next 50+ yrs.

So what I see needs to be done for the Tool to appear…

  1. Robust modeling methods to be used of various scales
    • ab initio methods with high precision for small systems,
    • semiempirics for systems around 1K atoms and more,
    • MM approximations for systems with 10K-100K+ atoms
    • continuous body approximations for larger systems
  2. Interfaces between methods listed above, so I can start model on macro level and drill down in most interesting features to discover what happens on atomic level
  3. Strong feedback from experimental methods:
    • compute what could be measured, preferably immediately
    • measure what could be computed
  4. Visualization, analytics and search systems to harvest the data, both computed and experimental

I still do not know how this should be enveloped for business purposes - I’m too far in software and away from product development cycles in large companies. Guess this would sort out on go.

The cornerstone is the modeling method and scripting glue, so that what I’d start with.

Changed comments engine

September 3, 2009 – 11:11 am

Tired fighting comment spam and blocking useful discussions. Thus switched from native WP comments to disqus.

The only drawback I see is that disqus failed to import old comments properly.

python coverage fails with ‘invalid syntax’ - solution

July 22, 2009 – 9:43 pm

If you get

class 'coverage.CoverageException'>: Couldn't parse '<filename>' 
as Python source: 'invalid syntax' at line 1

just make sure that your file has correct line endings. I’ve spent some time guessing until converted dos line ends to unix ones. :)

Django CouchDb adapter 0.1 released

June 23, 2009 – 7:54 pm

Although found couple not-so-minor bugs at last moment (as usual), django couchdb adapter is functional enough to support most of standard django admin.

Project trac: http://trac.khavr.com/project/django-couchdb/

Repository: http://github.com/42/42-django-couchdb/

Lean startup twitdump

June 23, 2009 – 1:45 am

Who to follow on twitter if you’re interested in lean startups: