15 February 2011

Test-First for Mental Health

I've been thinking recently about how a Test-First approach to development is good for our emotional well-being and psychological balance, and I believe this may be the most important reason to adopt test-driven  development.

Consider how we would traditionally develop software using a conventional Test-Last approach. We read our requirement spec (whatever form that takes), perform some design work -- as much as we feel we need to go forward with some confidence, and we start cutting code. Time goes by. Our codebase grows. We're doing some informal testing as we go along to feel confident that the code under development does what we think it should be doing...

And here's Important Point Number One: "the code does what we (the developers!) think it should be doing". Not what the business thinks it ought to be doing. See? We're inherently unsure -- even if only subconsciously -- whether we're doing work that actually serves the business. And unsureness is insidious and destructive to our well-being. We feel much better about ourselves as developers when we know that we're producing useful stuff that really has value. So here's the first way that having tests defined up-front helps us preserve our mental balance: With a reasonable set of tests1, defined together with our business partners, there's no bullshit involved; no trying to convince ourselves of the (probably shaky) value of our ever-growing codebase. We have an external, automated, objective, easily understood yardstick of value.

But there is, I think, a deeper psychological value to the Test-First approach.

So much of the time -- I will thumbsuck something like 99% of the time -- our code is broken. The system we're working on doesn't work. This is inherent in the fact that it takes us time to design and write software, and the continual not-workingness can be powerfully demoralising. Especially when we (finally, right towards the end of the project lifecycle) start formal testing, and our tester (often users) start coming back with bug after bug after bug after bug, and all that beautiful code we're so proud of is labelled "Less Than Satisfactory" -- usually in much stronger language than that.

Herein lies the secret destructiveness of Test-Last. Our code is always broken, and we can never do more than run after the brokenness trying to patch it up, until, at last, demoralised and exhausted, we move on to the next job or project.

Contrast this with a Test-First pattern.

We first write a bunch of tests. Sure it takes some time, can often be pretty tedious, and is frequently little more than a first-pass best-guess at what the code is supposed to do. Almost certainly we will add more tests as our code grows and evolves and begins to tell us the shape it wants and needs to be. But at least we start with a battery of (automated!) tests. And we start with the expectation of them all failing. This is by definition! We haven't written the necessary code, yet. A short time later we may have enough of the boilerplate in place that we can at least compile everything and actually run our tests, but we still expect them all to fail because our methods all read

throw new UnsupportedOperationExcetion( "TODO" );

So we run our tests, and they all fail. And we're happy about that! Everything went as we predicted. We feel in control.

As we go along replacing those stubbed-out methods, some of our tests begin to go green. We're making visible progress towards a well-defined end goal. We gain an ever-increasing feeling of confidence and accomplishment. We have tangible, objective evidence that we're making progress. Even when we make some of the "test bar" revert somewhat to red -- because we add new tests, or because we do some large-scale refactoring that breaks stuff -- we still feel good about it, because we know that our self-built safety-net is working! We've actually decreased the likelihood of things going wrong, so we know we're enhancing the quality of our product. (And every good developer I've ever worked with has an inner Proud Craftsman lurking in their soul.)

So it seems to me that Test-First builds our confidence and self-esteem as we go along, whereas Test-Last contains an inherently destructive, soul-sapping subversiveness to it.

I think this value outweighs the sum of all the other benefits (many though they are) of Test-First.

[1] Note that I make no distinction, here, between Unit Tests, Functional Tests, or System Tests (which would probably involve real databases, external systems, and so forth, albeit serving test data to our system-under-test.) I don't really care what form of Test-First is most useful to your team and situation. It's the principle that counts!

08 February 2011

Fusion Cuisine: Slicing and Dicing Courses to Suit Different Palates

Ever been faced with setting up training for some of your developers, but the courses offered by the usual suspects fail to cover the technologies your team uses? Or cover technologies that you don't use? Or lack the depth you're looking for in particular areas? Or too much depth...?

I was recently faced with a request from a client who want to put some of their junior developers through an Intro to Java course. The developers in question come from various other programming backgrounds, and already understand OO concepts and normal development disciplines. The "obvious" choice is the Sun/Oracle SL-275 mainstay course which I have been teaching (on and off) for something like 15 years, now.


But! A good part of SL-275 – and of my own Intro to Java course – delves into developing applications using the Swing GUI toolkit, used to construct desktop applications. This particular client is a company that only does web-applications, so learning a bunch of Swing concepts does them little good. I was happily able to propose that, instead of using Swing for that portion of the course, we could substitute some Servlet and JSP concepts and development. This arrangement serves them much better, as it also equips their developers with knowledge they will be able to immediately put to productive use. Fortunately I have lately put in a lot of work on a Servlet/JSP course, so I'm able to cycle some of that material into the Java Intro course.


It's not as simple as it sounds, though!

The Swing portion of "Intro to Java" also serves some other pedagogic purposes. It reinforces some of the OO groundwork covered earlier in the course by driving home the differences between inheritance, containment and usage. (At least it does the way I teach it!) Swing also provides a good platform for introducing listeners (Observer Pattern in the GoF book), Java's anonymous-inner class mechanism, and the exception-handling framework, along with a bunch of other bits-and-pieces that are useful for new-to-Java developers to learn, like converting between Strings and numbers.

So the challenge, now, is to make sure that I can adequately cover the same territory, and serve the same purposes, using servlets and JSPs. Not too hard, really, but it should make for a fun course where we can do a lot more hands-on, practical development work than the stock SL-275 allows.

The other tricky bit to watch is making sure that the level of detail doesn't overwhelm new-to-Java developers with too many web-application specifics. It is important to keep the focus on "Introduction to Java", and not lose sight of the real objective in a welter of webapp configuration and deployment.

Just a single, simple example of where and when customised courses can much better match the client's needs than any standardised, templatised training provided by a 4-week-per-month manual-pusher.
Contact me for a course customised to your organisation's needs!

18 January 2011

2011 Course Planning

Whew! Looks like March is going to be a busy month. I've planned no less than 3 courses back to back, so hard work ahead...

I'll be kicking off with the 5-day "Intro to Java" course on 7-11 March. It seems like Cape Town's demand for Java developers is insatiable. I've had requests from a couple of clients for this course simply because they just can't find good Java devs for their expanding teams, and they're going to be hiring developers with good OO experience from other (non-Java) environments and training them up for Java development as an alternative. Now, I know that any good developers loves learning new stuff, so I think these clients are doing a Good Thing by offering skills-development as part of their hiring process. My job is to give them the best possible Java Platform course, and I have great plans for delivering just that!

Next up will be the newly developed 5-day "Web Application Development with Servlets and JSP". If you've last looked at JSP technology a few years ago, possibly run away in terror at the sight of all the horrible in-page logic that made scriptlet-based JSPs such a nightmare for maintenance, then you really owe it to yourself to get up to speed with scriptlet-free, tag-based JSP development. The course includes topics on the new, new Servlet-3.0/JSP-2.2 enhancements that use annotation-based configuration.

And last, but not least, will be my much-acclaimed 4-day "OO Analysis and Design" course – thus fitting neatly into the 4 working days that remain after the Human Rights Day public-holiday.

I'm planning to run all the courses in Cape Town. (still looking for a great venue, so please drop me a line of you know of something extraordinary.)

Drop me a line if you're interested in any of these. Miss this opportunity at your own risk – I will probably not be scheduling courses in Cape Town again before August!

I'm offering an Early Bird discount of 20% to anybody who confirms a reservation before the end of January!

07 December 2010

Amazon Route 53: Trustworthy?

As a "user" of Amazon's Web Services (I've kicked the tyres on S3, but not much more than that) I received an email from Amazon punting their new DNS service, dubbed "Amazon Route 53".

I wonder though, in the wake of their termination of WikiLeaks, whether I would trust any part of my DNS infrastructure to Amazon. Suppose I did something to piss off the US governement - hosted a DNS entry for WikiLeaks, perhaps? at, say, http://wikileaks.mikro2nd.net/ - and some US government official notices (pretty unlikely, I know, but...) and whispers into Amazon's ear, would I, too, lose use of this critical infrastructure without review, recourse or refund?

So, no! I don't think I'll be using Amazon Route 53 much...

18 October 2010

HTTP Response codes & msgs as Java enum

Just in case it saves someone else the tedious typing... Capitalisation of messages duplicates the inconsistencies in RFC2616. Don't ask me...

    public enum HttpResponse {
        HTTP_100( 100, "HTTP/1.0 100 Continue\r\n\r\n" ),
        HTTP_101( 101, "HTTP/1.0 101 Switching Protocols\r\n\r\n" ),
        HTTP_200( 200, "HTTP/1.0 200 OK\r\n\r\n" ),
        HTTP_201( 201, "HTTP/1.0 201 Created\r\n\r\n" ),
        HTTP_202( 202, "HTTP/1.0 202 Accepted\r\n\r\n" ),
        HTTP_203( 203, "HTTP/1.0 203 Non-Authoritative Information\r\n\r\n" ),
        HTTP_204( 204, "HTTP/1.0 204 No Content\r\n\r\n" ),
        HTTP_205( 205, "HTTP/1.0 205 Reset Content\r\n\r\n" ),
        HTTP_206( 206, "HTTP/1.0 206 Partial Content\r\n\r\n" ),
        HTTP_300( 300, "HTTP/1.0 300 Multiple Choices\r\n\r\n" ),
        HTTP_301( 301, "HTTP/1.0 301 Moved Permanently\r\n\r\n" ),
        HTTP_302( 302, "HTTP/1.0 302 Found\r\n\r\n" ),
        HTTP_303( 303, "HTTP/1.0 303 See Other\r\n\r\n" ),
        HTTP_304( 304, "HTTP/1.0 304 Not Modified\r\n\r\n" ),
        HTTP_305( 305, "HTTP/1.0 305 Use Proxy\r\n\r\n" ),
        HTTP_307( 307, "HTTP/1.0 307 Temporary Redirect\r\n\r\n" ),
        HTTP_400( 400, "HTTP/1.0 400 Bad Request\r\n\r\n" ),
        HTTP_401( 401, "HTTP/1.0 401 Unauthorized\r\n\r\n" ),
        HTTP_402( 402, "HTTP/1.0 402 Payment Required\r\n\r\n" ),
        HTTP_403( 403, "HTTP/1.0 403 Forbidden\r\n\r\n" ),
        HTTP_404( 404, "HTTP/1.0 404 Not Found\r\n\r\n" ),
        HTTP_405( 405, "HTTP/1.0 405 Method Not Allowed\r\n\r\n" ),
        HTTP_406( 406, "HTTP/1.0 406 Not Acceptable\r\n\r\n" ),
        HTTP_407( 407, "HTTP/1.0 407 Proxy Authentication Required\r\n\r\n" ),
        HTTP_408( 408, "HTTP/1.0 408 Request Time-out\r\n\r\n" ),
        HTTP_409( 409, "HTTP/1.0 409 Conflict\r\n\r\n" ),
        HTTP_410( 410, "HTTP/1.0 410 Gone\r\n\r\n" ),
        HTTP_411( 411, "HTTP/1.0 411 Length Required\r\n\r\n" ),
        HTTP_412( 412, "HTTP/1.0 412 Precondition Failed\r\n\r\n" ),
        HTTP_413( 413, "HTTP/1.0 413 Request Entity Too Large\r\n\r\n" ),
        HTTP_414( 414, "HTTP/1.0 414 Request-URI Too Large\r\n\r\n" ),
        HTTP_415( 415, "HTTP/1.0 415 Unsupported Media Type\r\n\r\n" ),
        HTTP_416( 416, "HTTP/1.0 416 Requested range not satisfiable\r\n\r\n" ),
        HTTP_417( 417, "HTTP/1.0 417 Expectation Failed\r\n\r\n" ),
        HTTP_500( 500, "HTTP/1.0 500 Internal Server Error\r\n\r\n" ),
        HTTP_501( 501, "HTTP/1.0 501 Not Implemented\r\n\r\n" ),
        HTTP_502( 502, "HTTP/1.0 502 Bad Gateway\r\n\r\n" ),
        HTTP_503( 503, "HTTP/1.0 503 Service Unavailable\r\n\r\n" ),
        HTTP_504( 504, "HTTP/1.0 504 Gateway Time-out\r\n\r\n" ),
        HTTP_505( 505, "HTTP/1.0 505 HTTP Version not supported\r\n\r\n" );

        private final int intValue;
        private final String msg;

        private HttpResponse( int intValue, final String msg ){
            this.intValue = intValue;
            this.msg = msg;
        }

        public int intValue(){
            return intValue;
        }

        public String responseString(){
            return msg;
        }

        public static HttpResponse forResponseCode( int responseCode ){
            for( HttpResponse v : values() ){
                if( responseCode == v.intValue() ) return v;
            }
            throw new IllegalArgumentException();
        }
    }

13 October 2010

A Lesson from Vegetable Gardening for Hiring (and Keeping) Better Software Developers

Right now I'm in the midst of Busy Season in the Veggie Garden: Spring Planting Time. Even busier than harvest time. You see, you can almost always delay a harvest by a few days or a week without serious consequences. But you can't delay sowing seed without reaping serious consequences 4 to 6 months down the line. Veggie gardening is all about strategy.

Just the other day I heard about a successful and growing Cape Town company planning a hiring spree for Java developers. They'll be looking for quite a number of Java developers at all skill and experience levels.

But they face two key problems:
  1. There is an extreme scarcity of Java developers at any and all levels in Cape Town and surrounds.
  2. They'll be competing against a very large number of other employers looking for large numbers of Java developers. I have, over the past couple of months, heard of numerous companies searching for 10, 12 and more "skilled Java developers".
If you're in Cape Town you can probably take a reasonably accurate guess as to who those companies are. And they're not finding any developers, are they. Let alone really excellent developers...

This is great news for Java devs: Salaries are pretty competitive, even if not quite up to Jo'burg levels just yet.

Hell for employers, though.

Strategy is about Time

My main problem this Planting Season is that I don't have any compost for the garden. The key to making great compost is adding plenty of water, and the key to great veggie crops is building the soil by adding compost, year after year after year. But we're (still) in a drought, so no water. Successful crops are going to be a serious challenge this Summer...

CEOs, CTOs and Development Managers who get it know that investing in their developers' skills, knowledge and experience is investing in their own success and the success of their business. And the secret is that it can't be done overnight. It takes long-term commitment to helping their developers build their skills. And intelligent developers reward real, honest commitment to skills- and career-development with loyalty.

And developers talk to each other. In their mailing lists and user-group meetings, on Facebook and Twitter, word-of-mouth ensures that developers have a pretty good idea of who is doing the interesting software, who is providing a stimulating development environment. In short, who the good employers are. (Especially in Cape Town! The software world in CT really is a very small village.)

Compost making and soil-building is a strategic practise for farmers and gardeners everywhere, whether they are organic growers (like me) or not, soil-building is of vital strategic importance. Without healthy soil we have nothing.

Likewise, CEOs, CTOs and Dev Managers of companies for whom software development is a strategic business activity have a vital interest in developing their developers.

Planning to Hire Developers Any Time Soon?

If you are planning to attempt to hire developers (particularly Java developers; particularly in or around Cape Town) within the next 6 months, ask yourself the following 3 questions:
  1. How are you going to source the best and brightest devs when they're almost unreachable at any price?
  2. How are you going to make your company more attractive to those devs than all the competition you face?
  3. How are you going to keep developers from job-hopping when they get that email from a competing employer or headhunter offering them a huge raise?
If you have good answers to all of those, then please don't call me!

If you'd like help creating fertile ground for interesting minds who can help drive your software development to greater successes, call me.


05 October 2010

Duck Typing Developer Styles: 4 Ducks

Developers can be categorised along two orthogonal dimensions: coding-skills and design-skills. This post explains how to locate a developer according to this scheme, and describes how best to manage each development-style.


Tame Ducks are easy to manage, get on with the job, etc. They produce decent working code, but won't come up with the most innovative solutions. Great maintenance coders.

Wild Ducks are your innovators who will break new ground, but it's hard to get them to follow rules, comply with standards, etc. Give them the tough stuff to code.

Lame Ducks: deal with a Lame Duck by making Duck Sandwich. Sandwich the Lame Duck between a Wild Duck and a Tame Duck. They will either learn and gain competence, so becoming a Tame Duck in time, or they will Ship Out through fear of revealing their lack of knowledge.

QUACKS: talk a good project; strong tendency to bullshit their way through design by resorting to TLAs like SOA. XML and xDD. Deal with them by - again - making Duck Sandwich. The Wild Duck has exquisitely sensitive bullshit-detection capacity which, combined with their cultivated lack of tact and intolerance for freeloaders, will leave the Quack with no place to hide. The Tame Duck is there to back up the Wild Duck's assertions as to the Quack's actual performance. The Quack will almost certainly soon move on.

(Where do I fit in? ;-)

Credit: I first heard this Duck-Typing Scheme from an important mentor in my career, Nat Lunn, sometime around 1990, and so I must credit the whole story to him. Thanks, Nat!
Related Posts Plugin for WordPress, Blogger...