TurboManage

David Chandler's Journal of Java Web and Mobile Development

  • David M. Chandler


    Web app developer since 1994 and former Developer Advocate with Google now residing in Colorado. Besides tech, I enjoy landscape photography and share my work at ColoradoPhoto.gallery.

  • Subscribe

  • Enter your email address to subscribe to this blog and receive notifications of new posts by email.

    Join 233 other followers

  • Sleepless Nights…

    August 2006
    S M T W T F S
    « May   Sep »
     12345
    6789101112
    13141516171819
    20212223242526
    2728293031  
  • Blog Stats

    • 984,724 hits

Archive for August 9th, 2006

If You’re Too Busy, You’re Not Doing Your Job

Posted by David Chandler on August 9, 2006

Much has been written about the virtues of the lazy programmer, the one who never likes to write the same code twice. For the lazy programmer, coding anything once is fun because it’s a learning experience, but coding it twice is tedious. Not only that, but also it is dangerous because manual repetition means there are too many degrees of freedom for error. And not only that, but doing the same thing twice when you could have done it once is WASTE. One of the principal ways you improve throughput in any system is to eliminate waste (think for just a moment about your body).

The brilliance of the lazy programmer is that he can recognize when he has just done the same thing twice. Others don’t see they have done the same thing at all. In other words, the lazy programmer’s mind works at a higher level of abstraction. He can factor out the common code in the right dimensions and build abstractions so he never has to generate waste by writing that code again (and of course, this is fun because it’s a new kind of code). Then he sees the common factors in the successive versions of those abstractions, and after 10 years or so, can build something as beautifully well-factored as, say, JavaServer Faces.

I submit that the same ability for abstract thinking and automation are key requirements for Operations and QA, too. For an Ops guy to follow a standard procedure for system installations is mere competence (if the Ops organization has no such procedures, the Ops manager should be replaced–there is no excuse for such a lack of discipline). The truly great Ops people learn a system well enough to automate its installation and maintenance. They wield power tools with funky names like sed, perl, bash, and even InstallShield. They can run some command that will reinstall and reconfigure every server on the network in the event of a disaster and they know it works because they use the script for daily installs.

But, alas, like the lazy programmer, the lazy ops guy is rarely seen. In his place are (very) hard-working drones who manually repeat the same steps day after day, spend most of their time reacting to the perpetual crisis, and wonder why they live in a world of chaos.

If your Ops people are always busy, it might be a sign that they aren’t doing their job!

/dmc

Advertisements

Posted in Business of Software | Leave a Comment »

How to Hire Good QA People for Web Applications

Posted by David Chandler on August 9, 2006

A veteran software manager recently gave me same valuable insights on finding highly productive and effective QA people.

These two questions reveal a great deal about someone’s mindset and approach to software testing:

  1. How do you generate large amounts of test data?
  2. What are the pitfalls of automated Web testing and how do you get around them?

Unfortunately, the people running many QA organizations don’t understand these things themselves and wonder why their automated testing efforts repeatedly fail. Those rare few who do and ‘splain it to them are prone to get fired because it’s not safe to be smarter than the boss.Almost any programmer can tell you what you need to do to deep testing of a system: how to test each subsystem, how to generate meaningful test data that will really exercise the system, how to do positive and negative (no side effects) testing directly in the database vs. relying solely on what shows up on the screen, etc. In other words, the programmer knows more ways the system can (and can’t) fail because of their knowledge of how it works.

QA and Development should talk more often.

Posted in Business of Software | Leave a Comment »

 
%d bloggers like this: