Refresher Training is Good, Too!

Some while ago I was teaching a course -- Java Web Application Programming, as it happens --  to a group of quite-experienced web developers working in a large corporate environment. Needless to say, we all thought that this was yet another case of the Training Department getting their act together waaaay too late...

We soon discovered, however, that some of the core concepts and technologies of Java Web Application development were, at best, only poorly understood, even by the most experienced developers in the group. Many of the details of the HTTP protocol were unknown to them, as was the development of custom Tag Libraries -- a key component for developing clean, maintainable Java Web applications without in-page scripting. They had not thought much about the consequences of placing large (multi-megabyte) objects in the application Session... (this is in a clustered web-container environment!)

This is not a criticism of those developers! They had, for years, been delivering absolutely critical business functionality. This is merely an observation that technologies move on; sometimes developers need a little help to catch up, since their management usually neglects to allow time for self-study catch-up on new evolutions in the technology.

More important, it is an observation that Development Managers, Team Leaders and Project Managers shouldn't assume that their developers are completely up-to-date on the technologies they're using for day-to-day development.

---

Replicated from http://coco.co.za/wiki/KeyTechnologyTrainingStory

Nedbank Service Fail

<span style="font-style: italic;">Rant ahead. Feel free to leave now.<br /><br />No, really! This is just whining in public about the unbelievably crapulatious service Nedbank dishes out to its customers.</span><br /><br />A service I recurringly buy, and have repeatedly bought for... oh, probably more than 5 years, now... using the self-same <span style="font-weight: bold;">Nedbank</span> credit-card... came up for renewal yesterday. Mysteriously the transaction failed, so the vendor sent me an email to let me know. Very odd! As I say, it has worked fine for years. The card has not expired - the only reason transactions have failed before now.<br /><br />Oh well, off to pay the invoice manually. Using the same card, naturally. (It's the Business card, you see, so simpler for tax and accounting than using a personal card.)<br /><br />Next thing, I find my browser redirected to some foreign website "bankserv.co.za" for "verification". <span style="font-style: italic;">Oh yeah?!</span> There's a crappy, pixelated copy of a Nedbank logo at the top. <span style="font-style: italic;">That sure looks convincing!</span> And they're asking me for all sorts of account details, including my CVV number, ID number, and some arbitrary and mysterious field labeled only "Personal".<br /><br /><span style="font-style: italic;">What sort of phishing operation is this?</span><br /><br />Actually it turns out to be an alleged "Fraud Prevention" thing called 3-D Secure. I've only heard of it because I know people who have had the pain of implementing payment solutions that use it.<br /><ul><li><span style="font-weight: bold;">Question</span>: Why did Nedbank not <span style="font-style: italic;">bother</span> to communicate to their customers that they would be requiring this much-changed payment process?</li><li><span style="font-weight: bold;">Question</span>: Why do Nedbank not do it on <span style="font-style: italic;">their own website</span>, instead sending me to some website who's identity is a complete unknown to me?</li><li><span style="font-weight: bold;">Question</span>: Is this not the most incredibly stupid thing to do in a web where phishing and identity theft is rife?</li></ul>Later, a call to Nedbank's unbelievably crappy customer "service" centre illuminated a whole lot of these details. The bottom line is that:<br /><ol><li>Nedbank <span style="font-style: italic;">absolutely require</span> us to use this 3-D Secure thingie.</li><li>The shitty 3-D "secure" thingie absolutely requires that I enter my cellphone number to complete their process. Unfortunately, where I live, cellphone reception simply does not exist, so <span style="font-style: italic;">not an option</span>.<br /></li><li>So: I have no way to complete their crappy process, and</li><li>Nedbank has no other process.</li></ol><span style="font-weight: bold;">Fail!</span><br /><br />The 3-D Secure form did not even have a field labeled "Cellphone number". How is anyone supposed to guess at this?<br /><br />Then, too, there is no way to opt out. They claim that the 3-D Secure process is to "verify my
identity". This despite the fact that they have all my FICA docs on
record. They have my other business account details on record (because
that's how they get paid every month) and they manage to successfully
send me statements every month, and a new card every couple of years.<br /><br />And the process <span style="font-style: italic;">absolutely requires</span> that I be reachable by cellphone. What if I don't have or want one? What if I have one but can't get reception? Has anybody pointed out to the shit-heads at Nedbank that <span style="font-weight: bold;">SMS is not a secure nor reliable channel of communication</span>?<br /><br /><ul><li><span style="font-weight: bold;">Question</span>: Why would I <span style="font-style: italic;">jump through all these hoops</span>, put up with really shitty service and all this pain from Nedbank when Standard Bank (my other, other bank) have been trying to give me a business credit-card for years, only to be turned down (because why would I want <span style="font-style: italic;">another</span> credit card?)</li><li><span style="font-weight: bold;">Question</span>: <span style="font-style: italic;">How quickly can I close this Nedbank account?</span></li><li><span style="font-weight: bold;">Question</span>: Did anybody at Nedbank <span style="font-style: italic;">bother to turn their brains on</span> when thinking about this process, or were they - as usual - operating with their heads stuck so far up their own arse that they could see out their own throat?</li></ul><br />Oh! I paid the invoice using my personal credit-card (Standard Bank.) Payment went through flawlessly, painlessly and instantly with no hoops to jump through.

About Email

A short note on How I Handle Email communication.

Lately I've had a few people express their unease over my handling of emails, so I thought I'd write - once and for all - about how I deal with email. One of these was phoning me, worried, because I had not responded to her email within 15 minutes of her sending it. Another was complaining because emails I have sent him have never appeared in his inbox. It turned out that his ESP (email service provider) was having a Bad-Config Day.

Please remember that it is eMail. Not eInstantAnswer. Not eGuaranteedDelivery. Not eRegisteredMail. And humble though it is, I find it (still!) indispensable.

Share and Enjoy!

Healthy Software Projects

Love this little gem on eXtreme Programming: eXtreme Pill: Increase the odds of a lasting, healthy software project

start your journey with a Lean coach that also happens to know intimately what software development is all about

Though it seems to come as a shock to some that such coaches actually want paying! ;-)

The Way You (Probably) Use Subversion is Just Wrong

Trying to learn Hg (Take 2)  I learned something about Subversion: it seems that many people are using it all wrong!

Prompted by a conversation last week with Brian which touched on Subversion and Git, I decided to have another go at grokking distributed version control. I confess that I'm probably hopelessly brain-damaged on this score; I can't help it: I started out with version control systems in the days of SCCS, graduated to RCS, was forced to deal with the abomination that was PVCS, migrated to CVS, and have largely been reasonably OK (though not ecstatically happy) with Subversion for the past several years and a half. So I can't really be blamed for my difficulties getting to grips with distributed version control, can I? I learned all I know about the subject back in the Dark Ages.

But, hey! I'm a distributed worker kind of guy. I'm sure I can figure this out, even at my advanced age.

Rather than tackle the Swiss Army Chainsaw that is Git, I thought I'd give Mercurial a second go. I lucked into Spolsky's HgInit tutorial which seems a lot more approachable than other tutorials I've seen to date, and a lot shorter than The Mercurial Book. Almost immediately I ran into a passage that stopped me short with the thought, "If this is how people are using Subversion, no wonder they want to move onto something better!"

Joel on Subversion

Now, here’s how Subversion works:

* When you check new code in, everybody else gets it.

Since all new code that you write has bugs, you have a choice.

* You can check in buggy code and drive everyone else crazy, or
* You can avoid checking it in until it’s fully debugged.

Subversion always gives you this horrible dilemma. Either the repository is full of bugs because it includes new code that was just written, or new code that was just written is not in the repository.

As Subversion users, we are so used to this dilemma that it’s hard to imagine it not existing.

Subversion team members often go days or weeks without checking anything in. In Subversion teams, newbies are terrified of checking any code in, for fear of breaking the build, or pissing off Mike, the senior developer, or whatever.

No, that's not me he's talking about; that's some other Mike.

Wrong. All wrong!

As luck would have it I was discussing repository-management strategies just last week with a client's (new) development team, and suggesting that they use a much more aggressive strategy than they've ever seen before: Multiple checkins per day by every developer. Maybe go so far as to tie the "File-Save" key to "checkin". Anytime a developer does not make a checkin for 2 days in a row there's almost certainly a problem!

How do we achieve this without the tears and craziness described by Spolsky? Simple! Have every developer working in their own private branch. Or even flipping between a variety of private branches as they switch between tasks. (Yes, I know its not the most productive way to work, but sometimes we have to respond to demands from the outside world, so we do have to take the hit of task-switching.)

I suggested a structure where each developer simply gets a private piece of the repository to work in. Anything that's broken in there is your own problem, but doesn't affect anybody else on the team. When you're satisfied that your branch won't break the world you're ready to merge back to the main development line and integrate your work with your colleagues'. And yes, then you might have some merge conflicts, but I don't really see how any version control system can avoid this; you fix the conflicts and 'Lo! the build is intact. This does imply, though, that you want to merge quite frequently. At least every day or two. Or every time your private branch builds and tests clean. Or maybe just builds clean. All depends on your team - team size, maturity, process-maturity, personal temperaments,... One must study this very hard.

I suppose that the hangups about branching and merging come from the days of CVS, where branching was really, really expensive, and merging really, really difficult. Admittedly, too, earlier versions of Subversion were also not too hot on the merge side of things. (Though I guess it is still work-in-progress and we may yet see some improvements there.)

In recent times I have been using Subversion branches very aggressively. Frequently I'll find myself flipping between as many as 6 or 8 branches on related modules, merging them, abandoning them,... and this is on a one-man project! It means that I have to use branch-names that are pretty long and descriptive, otherwise I would soon lose myself in the forest of twisty little names.

But really, I don't see the dilemma Joel talks about in the quote above. I'll readily agree that Subversion's merging still needs some work: It can be quite counterintuitive and error prone until you get the habits right. But this Big Hairy Deal about breaking the build? Doesn't exist if you just use Subversion right!

Go forth and branch!

Maybe I'm making a mountain out of a molehill when it comes to Hg... Maybe I'll fall in love with it yet, if it makes this style of working easier for me. There's hope for the old fart, yet.

Cogito Ergo Wiki

For your entertainment and delectation, I offer up a small write-up in which I muse about complexity and simplicity in the tools we choose to inflict upon our project partners.

A short excerpt:

I think that WikiMedia is a relatively terrible thing to inflict upon unsuspecting project partners who are already stressed out by the weird idea that they should contribute documentation to your project, that they might actually be asked to actually write something

Wiki Wondering: Share and enjoy.

Those Damn JavaStations Just Won't Go Away

Actually, this thing - going by the dubious name of 'zero client' - looks to be something more like a SunRay than a JavaStation NC.

I have what is probably one of the only production JavaStations left in the world sitting downstairs - by the front door - waiting to get dumped for recycling. It is not one of those original concept JavaStations - youknow, the one that looked like the Heart Of Gold starship with Infinite Improbability Drive. Rather it was one that actually worked, looking more like a conventional PC, but with an odd (smart-card) slot in the front. It was part of a special production-run that Sun did for a client about 10 years ago which deal fell into disarray when the Left Hand of Marketing failed to talk to the Right Hand of Management at Sun, and they canned the entire JavaStation concept. As a result a couple of thousand of these JavaStations got dumped and the customer got the contract fulfilled by other means.

Actually, it would make a nice X terminal when running Linux. You'd just have to reflash the BIOS.

It occurs to me that there must be some JavaStation nostalgia buff out there that might want it. Any offers?