Wille Faler’s Buzzword Bingo

A LOT of organizations have a build manager for their software development, or even in some cases a dedicated team for build- and configuration management.
To me, this is a big, red flag that the organization is doing something seriously wrong.
In todays age, with all the build tools and other tools for automation that we have at our disposal, there is absolutely no need whatsoever to have a dedicated team for building and configuration management.

I can understand that organizations need to have a defined process, and maybe an “owner” of certain environments (such as a production. staging or testing environment), and that people shouldn’t deploy on an ad-hoc basis to such environments.
But that is still no reason for having a whole team of people dealing with a build - a reasonably organized and talented development (or maintenance) team should be able to create a build script and process whereby building a software release is as easy “pushing a button” and then providing whoever is deploying an application with a file to do so.

If you feel the need to add people just to manage a build and configuration management system, take a step back - more likely than not, you could just pinpoint the problem and find a way to automate the relevant process.

I am currently lamenting my lack of time, for anything. Besides my 9-5 engagements, I have so much I want to do:

• Develop and improve Wicket RAD (where most of my time outside regular working hours is spent currently).
• Learn Objective-C and Cocoa (I have a few ideas for Mac and iPhone apps that I’d love to implement).
• Work on my Amazon EC2 and S3 API’s and features (not much, if any time spent there currently).
• Continue reading up on Bayesian classifiers and other data filtering and selection algorithms and tools.
• ..actually have a social life from time to time (with the “todo’s” mentioned above and the drain on energy it means, it’s hardly surprising that I am single again since a few weeks back).

For now though, the priority remains Wicket RAD, although I’m hoping that I will soon have one or two more people contributing to it, so I won’t be the lone developer working on it anymore.

I know it’s not very nice to highlight-, poke fun at- or ridicule other peoples mistakes, but this one was so bad, I couldn’t help myself.. A colleague of mine came across this piece of code earlier today (somewhat obscured to protect the not-so-innocent):

try {
    Class clazz = Class.forName(”com.someorg.Foo”);
    Object o = clazz.newInstance();
    Method setBar = clazz.getMethod(”setBar”, new Class[] {int.class});
    setBar.invoke(o, new Object[] { baz });
    return o;
} catch (Exception e) {
    e.printStackTrace();
}

..it is wrong on so many levels, I don’t even know where to begin. Every line is a glaring mistake.
Whatever is wrong with:

Foo foo = new Foo();
foo.setBar(baz);


The original code at the top instantiates a specific class, invokes a specific method through reflection, all of it hardcoded, why oh why would anyone ever want to do that? (Note: I haven’t even mentioned that the Exception just gets swallowed into oblivion, maybe or maybe not visible in some log somewhere..).

I will be holding a presentation/introduction to Wicket RAD at the next London Wicket User Group meet-up on the 6th of August at 6:30pm. The meet-up is held at Google UK’s head office, which is very close to Victoria Station in central London.

There will also be a couple of other interesting presentations, and the events are usually very enjoyable, and for those who want to, there are usually beers in a close by pub afterwards.

Details and a registration form for the LWUG event can be found here.

Picked up a nugget on TheServerSide, which I thought was worthy of highlighting on my blog:

Any serious manager will always go for standard solutions, such as JEE, simply because it is less risk.

Now, to play the devil’s advocate for a second: WHY is it less risk?
4-6 years ago, everyone went crazy for EJB’s because it was “a standard and hence less risk”. Now most people who adopted them are in a right mess: they can’t upgrade their JVM’s or app servers because it is too big a risk, they can’t improve or extend their codebase because it is too big a risk since EJB’s are almost untestable (and even if they where testable, good luck retro-fitting fitting tests on container-based code years after the fact).
On the other hand, anyone who went with writing in mostly plain Java have been able to continue on their codebase and update JVM’s & app servers to their hearts content.

Just stating something is “less risk” because it is a standard doesn’t make it so. Sometimes you actually have to think about what the actual, real risks are.

SproutCore, a JavaScript framework for building thick, browser based clientside applications is being bandied around by many as the Next Big Thing(tm), much due to Apple’s adoption for mobileme.com, a desktop like suite of webapps for Mac owners. The demos look impressive, I have to concede that, but..

The next big thing? I don’t think so, more like a step backwards in time. Look at this code example:

<%= label_view :my_label, :tag => 'h1', :bind => { :value => 'HelloWorld.appController.greeting' } %>

Yuck! Doesn’t that look a whole lot like old school JSP’s with scriptlets, prior to even any taglibs being around?

If someone thinks programming in Javascript and jumping back in time to 1999 in terms of developer productivity is a good idea, well.. Then I’m not going to comment on that by saying anything more than: “not a great idea”.

If someone can provide compact, nice, clean Java- and/or .Net API’s that encapsulate all of the Javascript horror, then maybe. But as it stands now, I don’t think any amount of bells and whistles justify making webapps slower to develop, harder to test and more complex.

There is one thing that never stops striking me when I come across it: the vast gap between the value that good software developers/architects provide for their clients and employers, and the appreciation of that value shown by clients and employers.

It seems that most of the time, organizations are prepared to bite the bullet of paying quite handsomely for good software professionals, but if they can think of any way not to, they’d rather not: there seems to be some ingrained notion in many peoples heads that software development is somehow a menial and lowly task requiring little to no skill, that can be taught to anyone given a weeks “handover”.

I’ve seen this being expressed many times over: By having the highly paid, highly skilled people being divorced from hands-on development, instead being expected to provide “architecture” and “designs” for an army of lower paid, considerably lower skilled developers.
I’ve even seen cases where companies have given notice to their skilled developers, to then have them “teach” everything they know in a week to some offshore team that are actually web designers/html-jockeys!

As if knowing how to crank out a static web page with some text on it was the same thing as writing scalable software for integrating diverse information systems!

What seems utterly lost on people with this mindset is that skilled software professionals are highly paid for good reason: they have a scarce skillset that takes years and years to pick up and hone. Even the difference between an experienced, highly skilled developer, and that of a junior unskilled developer can be that the experienced developer can do things in no-time, that the junior developer would not be able to pull off given infinite time!

A good metaphor for this situation is that of trying to make a woman give birth in a month by impregnating 9 women - adding women to the equation won’t hasten the delivery, because the quantity of women is not the cause of the problem in the first place.
In raw economic terms, it makes more sense to pay a highly skilled person £600 a day to perform a task that takes him a week to finish, instead of paying 4 lowly skilled people £100 a day to perform a task that they will never be able to finish.

How this appreciation gap has come about, is beyond me, but I think it has to do with people thinking of software development as if it where conbeyor belt industrial production, whereas in reality, it is actually new product development - it is actually designing both the product, the conveyor belt, and the tools and processes around reproducing the product.

Admittedly, I’m a bit late to the game when it comes to learning hands-on about Amazons Elastic Cloud Computing (EC2) and Simple Storage Service (S3), but I’m glad I’ve put in the time during the last few evenings.

There are a few niggly bits to get over, but when it all comes down to it, they are actually helpful: there is no persistent storage for your server instances in the cloud, which means you will loose any files or databases not backed up if your instance crashes. But I’ve actually found this useful, it has really made me think about how to best do frequent backups to the S3 storage, how to automate backups and restores if instances go down, and actually test that all this work.
How many people can actually say that they have put their backup- and restore strategies to the test? I think most organizations think about them, pay lipservice to it and have something in place, but it is rarely properly tested, with the consequence that from time to time they fail.

One thing that is easily addressable annoys me though - all Java API’s for Amazons Web Services are extremely poor, there are a few out there, but they are all subpar, including Amazons own. I guess this is down to Amazon preferring that people roll their own and simply use the RESTful http API’s that they provide, which are actually quite good.

These little annoyances got me started in writing my own Java API on top of S3, that will encapsulate the (small) complexity of the REST API’s in something that looks more akin to a regular “File system” interface for Java, but one that still gives you meaningfull Exceptions when things go wrong. I might go on writing some tools for management of EC2 instances too, and roll it up into a bundle and release it as open source, we’ll see about that (I have quite a lot on my plate at the moment, with trying to make an imminent release of Wicket RAD as well).

Overall, I’m starting to really like the concept of not having to pre-emptively know how much storage I need, or how many/how powerful servers I need, I’ll just increase capacity as I go along!

Recently, I’ve been entertaining the thought of using Maven as a potential deployment environment.

Sure, Maven is a build tool first and foremost, and it also has its fair share of quirks and idiosyncracies, but not anymore so than just about any J2EE/JEE server, and you’ll certainly get less bloat.
The combination of running something such as an embedded Jetty server via Maven, with the nice dependency- and version management of Maven certainly is appealing, it definitely makes for an environment that is bloat free, runs exactly the software it should run and minimizes the risk of having some obscure dependency conflict in the server cock things up for you. The fact that you can tailor your “server” just about anyway you want easily and programmatically is just the icing on the cake.

The thing you might loose if you are of an “enterprisy” bent might be the management and monitoring capabilities of something like Websphere or Weblogic, but then again, in my experience this is usually mostly hot air: people talk a lot about using those capabilities in the early phases of projects, but end up using almost none of it once it comes around to running the resulting application in a production environment. And if you really need it, there’s nothing to say you can’t do it easily yourself, with more fine-grained and context appropriate control.

I’m quite encouraged by the feedback I have received for Wicket RAD - the little RAD web framework (built on top of Wicket and JPA) that I have been working on recently.

I have had quite a few e-mails about it, and to date, it has been downloaded 944 times(and counting..) in the ten days since the first release, which is way beyond anything I expected in such a short space of time. A lot of that traffic has obviously been driven from the mention on TheServerSide.

I had an interesting Skype talk with a couple of guys today (names not mentioned, as I don’t know if they want to be mentioned, and haven’t asked for their permission), where a few quite good ideas where given to me, with more to come.

I think that one idea put forward by the guys was particularly good, and idea which I myself have toyed with over the last couple of days, is the idea to make Component generation metadata agnostic - in other words make the annotation- and bean-driven approach currently used just one of several possibilities.
Other future possibilities could be being able to generate forms with validation and other components straight from the metadata of an SQL database table or a CMS repository.

I already have a few ideas about how to go about this, that won’t change or impede the ease-of-use of the annotation-driven bean approach, and won’t convolute the code. I have already implemented a first stab at this for property-validation, where annotations are still used for metadata, but the retrieval of IValidators for the generated form is not dependent on this being the source. Anyone wishing to get early access to this can obviously have a look in the SVN repository (or simply browse SVN with a browser).

I think considering that the annotation driven bean form generation is already semi-mature, the metadata agnosticism will be the thrust of the effort in the short term, with a new release hopefully being made in the next week or two (time and neglected girlfriend permitting).