Software Reality

Code Bubbles and Porky Visual Studio

Here's my latest article at The Register:

The latest incarnation of Visual Studio had a difficult gestation, with critics pointing to the slowness and instability of the beta release...

... This isn't just a criticism leveled solely at Visual Studio; it's against all the modern IDEs out there - VS in day-to-day use is not so different from what we were doing with the first version of Visual Basic 19 years ago. Somehow, Microsoft managed to fatten Visual Studio up to porcine levels and yet using the product feels like you're trapped in the 1990s.

Java IDEs suffer from the same problem, to an extent. IDE evolution has become a game of feature creep, each new release touting bold new features, drawing in concepts well outside an IDE's core competency - half-baked UML support springs to mind - and packing it all into a single frame. The notion of "doing one thing, and doing it well" has been laughed out the window.

And the reason for this stagnation of innovation in the IDE space? The industry leaders have become portly, comfortable, and middle-aged. Eclipse is smoking its logical representation of a pipe, content to let plug-in developers pad out its ecosystem. NetBeans plays perpetual catch-up while its fate is decided for it. IntelliJ no longer sells itself on productivity, having fallen into the "feature checklist" trap.

The time is ripe for a brand-new contender to stroll in with something fresh and steal developer mindshare from beneath the leaders' pipe-yellowed moustaches - just as a young Eclipse once did to NetBeans.

The bubblicious Code Bubbles IDE could be just that new contender. It puts a leash around Eclipse to do the donkey work for it, but invents an entirely new front-end so that programming becomes more like playing with Matey in the bath. A prototype from Brown University in New England and video about Code Bubbles has passed the frothy developer test, with viral emails flying around the workplace.

>> Read more at The Register

Don't blame Willy the Mailboy for software security flaws

Here's my latest at The Register:

There's a low rasp of a noise being made in the software world. Customers want software vendors to hold programmers responsible if they release code containing security flaws.

Actually, that's not strictly true. Security vendors want customers to start wanting software vendors to hold the programmers responsible.

As we recently reported, the annual Top 25 programming errors announcement urged customers to let software vendors know that they want secure products. This desire is captured and bottled in a draft Application Security Procurement contract provided by security certification vendor SANS. The majority of the contract discusses liability in terms of the vendor. But the occasional clause stands out, like this one:

Developer warrants that the software shall not contain any code that does not support a software requirement and weakens the security of the application...

In other words, when it comes to application security and QA, the buck stops with the developer. And that's in a contract that likely won't even be seen by the developer and will be signed on his behalf by his employer. It renders the contract unenforceable - so why add a clause like that in the first place?

It reminds me of the Dilbert book Bring Me the Head of Willy the Mailboy. No one wants to take responsibility, so the blame is passed down through the ranks in an Ayn Rand-ian shoulder shrug, until the atomic unit in the trenches (the programmer) is reached. The process has failed, management has failed, QA has failed and the customer's blood is boiling. So the answer's obvious: sue the little guy!

Read the full article at El Reg.

Programmer Archaeology - The perils of joining a mature project

The majority of software projects are ongoing efforts - never ending cut-and-release marathons. New screens and functions are released on (or around) specific agreed dates, but the project itself keeps on going. So it’s far more common for developers to join a project mid-flow, with its own dusty corners that no-one dares to disturb, its homegrown O-R mapping frameworks, crusted together with the foibles and wrinkles of a dozen long-since-departed self-styled code gurus.

By contrast, starting a brand new project from scratch is a rare joy: the opportunity to set the standards, consider the architecture, evaluate the available technologies given the business requirements; and to produce clean, maintainable code that’s easily unit-tested.

Ah, that last one. There’s nothing quite like the pain of joining a “mature” project and discovering that unit tests were never even a glimmer in the eyes of the project’s founding coders; the forefathers who laid the treacle-like foundations for their successors to follow.

Like a Spanish explorer in a South American jungle, you’re unlikely to find a lost city of gold; instead, prepare to discover the overgrown remnants of one long-lost programmer’s vain attempt to add unit tests - a strained nod toward provable code quality, quickly abandoned when the poor programmer was beaten back by the tangle of dependencies, the onslaught of complex constructors and static initializer blocks like Aztec ghosts sending the programmer scrambling to the far end of the jungle.

Design Driven Testing - New book on the way

EDIT: DDT is now available as an alpha book from Apress. 5 chapters are available to read right now!

Just what the world needs, another book on Test Driven Development (TDD)??

Well not exactly... Along with co-author Doug Rosenberg we've recently signed up with Apress to write a book about automated testing (i.e., unit testing, acceptance testing, new-kid-on-the-block behavioural testing, and requirements testing).

But... this won't be your everyday "toe the party line" automated testing volume that regurgitates the TDD doctrine. Instead, we're making the point that TDD is, to put it mildly, ass-backwards. Tests shouldn't be the sole design driver; instead the design can be used to identify the key areas of the code to cover with tests. In other words the design should drive the unit tests, just as requirements drive the customer acceptance tests.

We've found that, while it has much in its favour, TDD represents too much work for what you get out of it. For example, we definitely don't recommend that you go all-out for 100% test/code coverage, because you'll never achieve it in the time available... so what's the measure of success? How do you know when you've written enough tests and it's time to stop? Instead, we believe you should "test smarter, not harder" - in other words, identify the key areas of the code that will benefit the most from tests.

There's a chapter on Design Driven Testing in our previous book, Use Case Driven Object Modeling with UML: Theory and Practice. However, in this new book we'll be exploring in much more detail the ideas and the practicality of automated testing, using a real-world, non-trivial project ("Mapplet 2.0") being developed at ESRI for a travel website. This project will use a Flex front-end hooked up to Java server code, which in turn connects to a hotel search XML database and ESRI's ArcGIS Server. So we'll be exploring how to go about unit testing an enterprise application with a mix of languages and technologies (just like the majority of real-life projects out there).

To top it all, Sparx Systems has developed an ICONIX Process add-in for their UML modeling tool, Enterprise Architect (EA), which automates many of the steps that we'll cover in the book. You don't have to use EA to use Design Driven Testing, but after seeing what's possible with the emerging tools support for the process, we believe you'll want to!

Stay tuned, I'll post more about the ideas behind Design Driven Testing over the next few days.

“Mom, Java’s stopped working again!” (At least until we get Closures)

I can imagine this cry continually being shouted out in back bedrooms, cube farms and open-plan agile pigpens alike. Every couple of years or so, a new feature is mooted that will enhance the Java language, ostensibly to make it more “modern” and keep it competitive with the likes of C#, Ruby, and even (who woulda thought?) JavaScript.

As soon as the proposed new feature appears on the horizon, excitement bubbles up. Arguments break out on community hubs such as JavaLobby and TSS, where developers swear blind that they can’t possibly be an effective Java programmer without the new feature – in whatever form it ends up taking. (Okay that’s a slight exaggeration, but reading some of the threads, it does feel that way!)

Comment judiciously, refactor if needed, avoid the 'f' word

My latest article over at Reg Developer:

Comments can be abused as easily as any other tool or technique. You know comments - and, indeed, the project - have become dysfunctional when you start to see gripes and swearing, or flames concerning either the code or the individual who wrote the code.

When the Windows 2000 source was leaked a few years back the code was, to Microsoft's embarrassment, liberally infused with the bitter side swipes and literary headbutts of some deeply frustrated programmers.

Read more at Reg Developer...