Wille Faler’s Buzzword Bingo

My post about my switch from Eclipse to NetBeans has drawn a lot of traffic and comments over the weekend. In the discussion I have heard some people voice concerns about NetBeans future under an Oracle owned Sun, since Oracle have been in the Eclipse camp previously.

I share the concern, competition is important for the IDE eco-system. However I don’t see it as a make or break issue, first of all NetBeans is already open source, I would guess that it would have a vibrant developer community even without Suns active stewardship.

Secondly and more importantly, any developer worth their salt should be able to work with any IDE, or even text editor. An IDE is only a productivity tool, it should help our work, not be an absolute prerequisite to get the job done. I grew into Java using primarily Emacs and JEdit in combination with the command line, and later tools such as Ant and Maven. When I started using Eclipse it was because it was recommended to me by colleagues and I eventually found it helped me get things together (first ever help I appreciated: generating getters/setters).
I started using Eclipse because it made me work faster, I stopped using Eclipse recently when it started getting in my way of getting things done.

Should NetBeans stagnate, I would probably still find it useful as it is not in the way and helps me being productive. Should it dissapear I would look into IntelliJ (biggest hindrance for IntelliJ adoption: I’m cheap and law abiding at the same time). Should the Eclipse project decide to get their act together and start making Eclipse a productivity tool as opposed to a hindrance again, I would give it a second look.
If they all fail miserably and become obstacles in the future, I’ll just use a text editor with syntax highlighting, like TextEdit in combination with Maven2 or whatever build tool is at the top at the time (I’m quite curious about the progress of Buildr).

The point is: IDE’s are at their best a good tool to boost developer productivity, and a good developer should be able to work well with any IDE that isn’t an active obstacle to their work. However if a developer hinges his/hers whole career and professional future on specific IDE’s or IDE features, they are in the long term effectively committing career suicide.

In the last month or so, it seems the visitor stats for this blog have shot through the roof, so I realize I might have a few new readers who come back occasionally.

For this reason, I have created a FeedBurner feed, so I can get a better feel for how many actually read it, so if you subscribe, please use that feed. Also, if it is not too much trouble for existing users, it would be greatly appreciated if you would repoint your subscriptions to this feed.

For those of you who are into Twitter, you can also follow me on Twitter where I probably tweet way too much..

Thank you very much for your attention, and feel free to comment on blog posts – often the discussions below posts can be more interesting than the posts themselves!

About two weeks ago I decided to give NetBeans a real go again. The last time I used NetBeans in anger was around 2002-2003 for Swing development, which it was quite good at, although I never felt at ease with NetBeans somewhat clunky and resource hungry ways.

Since 2004, I have been using Eclipse almost exclusively – when Eclipse 3.0 came out, I was sold on it, it was everything I ever wanted in an IDE after years of trying IDE’s only to fall back to more old school editors like Emacs and JEdit. However in the last year or two Eclipse has started to frustrate me for a number of reasons:
It has started to bundle way too much functionality, making it very heavy weight, it frequently crashes or becomes unstable with workspaces that are big, its roundtrip compilation does not always keep up, resulting in errors that are non existent being reported, imports not being recognized or short cuts not working properly, it doesn’t keep its own workspace and the filesystem in sync without manual refreshes, and perhaps worst of all, it reinvents everything for itself, rather than leveraging existing tools on your machine.

When switching to NetBeans I was pleasantly surprised by how its UI had turned, well, modern. I’m still struggling to navigate and use shortcuts compared to Eclipse, but the lack of the laundry list of frustrations in Eclipse still makes it a more pleasant and productive environment. But for me the real killer feature in NetBeans is that it leverages your environment.

How revolutionary: it uses Maven in my path for Maven commands. It uses Subversion on my path for Subversion, rather than reinventing it with some halfbaked, buggy partial implementation!

I’m definitely a convert to NetBeans from Eclipse. NetBeans reminds me of Eclipse 4-5 years ago, before it lost its way. It’s reasonably lightweight, and does what it does without throwing hissy fits every five minutes.
NetBeans is like the long lost love that has aged with grace and dignity, retaining the characteristics that made you love her in the first place, whereas Eclipse is like the aging, overeating trophy wife who thinks she’s still “all that” and lets you know about it, frequently.

20% time is lost to context switching per ‘task’, so fewer tasks means less time lost
(Gerald Weinberg, Quality Software Management: Systems Thinking)

I saw this quote today in an article on DZone, and a penny dropped for me in terms of comparing software systems to people: Both people and software systems start struggling with “performance” if they get overloaded with concurrent tasks. In itself not a revolutionary discovery, not even a discovery, but the parallell is spooky.

One of my eight points for highly scalable systems was to restrict concurrency for computationally heavy tasks – because quite often a system will be quicker at dealing with a queue of sequential tasks, rather than do all of them at the same time (with “too many concurrent threads”).

Maybe my eight points for highly scalable systems can be applied to personal productivity? Off the bat I can think of the following parallels:

System practices: Constrain concurrent access to limited resources + Staged, asynchronous processing.
Personal practice: Do as few tasks as possible at the same time (preferably one), do tasks sequentially rather than concurrently.

System practice: Minimize network chatter.
Personal practice: Minimize interruptions.

System practice: Offload the database.
Personal practice: Offload your brain – only memorize and pay attention to the details that matter right now, put other things in storage outside your brain: notes, todo’s, calendars etc, or just ignore them.

System practice: “What a difference a cache makes”.
Personal practice: see above, use computers and paper to note down details that are important, but that take too much energy to memorize.

System practice: Don’t store transient state permanently.
Personal practice: Ignore details that are of no importance for what you want to achieve. Willful ignorance gives focus and doesn’t clutter your brain with unnecessary detail.

System practice: put things close to where they are supposed to be delivered.
Personal practice: put things close to where they are supposed to be delivered – pack your bag and leave it at the door before you go to bed, leave your first actions at hand the next morning as a note on your keyboard etc.

These points may feel a bit forced, I know, but my point here is not the eloquence of the individual practices above, but rather that the human brain and a software system are not necessarily that different when it comes to performance/productivity – similar practices to what makes your software systems scale, might applied to your personal life also scale your productivity.

“I’ll create a GUI interface using Visual Basic…see if I can track an IP address.”

CSI New York tries to apply technobabble to awe viewers with their incredible crimefighting powers. Hilarity ensues.

Read all about it here.

Yesterday evening I met a friend who works at a investment bank over drinks. He mentioned how ironically enough the massive layoffs in the department he works had made the organization able to get more done – the layoffs where by no means perfect, lazy people where still there, good people had been made to leave, but overall the increased accountability of a smaller organization had made the whole department function more efficiently.

This pretty much mirrors my experience over the last ten years. When an organization grows beyond a size where immediate accountability can be demanded, people start hiding behind excuses and the work of other people. Organizations that grow beyond say 10 people tend to take on characteristics of being daycare facilities for white-collar workers, rather than for-profit businesses – people will come in, sit off 8 hours, make up excuses for their non-performance, and have their managers just accept it, because most of the time they are just as culpable, and if they’re not, it’s not their money being paid out anyway.

Have you ever wondered how some IT projects can employ thousands of people for years on end, yet deliver nothing (*cough* public sector *cough*), while small entrepreneurial organizations deliver more value with three people in a manner of weeks or months?
The answer is simple: management are also the owners, it’s their money on the line. Employees are accountable, and if they don’t deliver the business is in jeopardy and by extension their jobs. There is nowhere to hide, there is no one elses money to spend and burn through. Once these characteristics are lost, and once the employees and management get more and more divorced from these interests, an organization slowly starts rotting and dying from the inside.

It might be a bit of an exaggeration to say that no organization should be bigger than 10 people, but it’s not far off considering the internal rot that starts setting in beyond that point.
Small autonomous teams will always trump faceless bureaucracies. Small is beautiful.

This is not a movie review blog, but I’m guessing there’s a fair amount of overlap between people interested in software and entrepreneurship, and trekkies..

I saw the new Star Trek movie yesterday and thoroughly enjoyed it, it is probably the first Star Trek movie ever that will appeal to a wider audience (although I have a soft spot for Wrath of Khan and First Contact as a “trekkie”).
Although there is an annoying amount of lens flaring and too much camera movement at the beginning, the cinematography is impressive.
The makers have also managed an impressive feat in keeping much of the look and feel of ships and wardrobe from The Original Series, while at the same time giving it a modern feel so it is neither dated nor cheesy.

The acting is impressive, and a lot of the mannerisms and personalities are the same, without falling into mimicry – all the actors put their own stamps on the roles, without loosing what made the original cast appealing. The actor who gets closest to being a carbon copy (and in an impressively good way) of the original cast is Karl Urban in the role of doctor McCoy.

With regards to the story line, well, I’m torn: it is a great story, but there is a major “non canon” event in the movie which may rile some trekkies (I’m mostly concerned about its repercussions), an event that at the same time establishes this as a proper “reboot” of the franchise in a completely new Start Trek universe (parallell universe/timeline if you will in proper Trek parlour). To ease the bridging between the old universe and the new, Leonard Nimoy reprises his role as an aging Spock from the future, something which will no doubt make a lot of trekkies cream their pants in joy.

The bulk of the movie goes into establishing the characters, their backgrounds and their character development, perhaps more so than any Star Trek movie since “The Wrath of Khan” (in which Kirk deals with being middle age..). I found it very interesting to see where the characters came from, and how they became what they where to become.

Overall, the Star Trek movie is an exhilirating ride which will probably appeal to non-trekkies and trekkies alike. Personally, I’d give it an 8/10 rating, which could go up to a 9 IF the makers deal with the major non-canon event in a satisfactory way in any upcoming sequels.
As you might have gathered, the major “shifting event” in the movie, which I will not spoil is the one thing that concerns me a bit as a Star Trek purist and enthusiast.

Here’s a revolutionary idea: don’t store non-relational data in a relational database!

Having a relational database is almost a foregone conclusion on most projects, as is the assumption that most, if not all data will be stored in it.
But is all of your data really relational? Do you really need to cram everything into a database, like square pegs into round holes?
“Square pegs in round holes” is an accurate analogy for the way data is stored in a lot of applications – relational databases are unfit to store files, they are terrible at dealing with lots of user defined custom fields, they are less terrible at dealing with heavily hierarchical data but still end up struggling if a lot of hierarchy traversal is needed.

I can quickly think of a couple of “for instances” where relational databases are a terrible idea – contact databases and bug tracking software that allows for custom fields. Who has not come across the infamous “property table” in a relational database as a “solution” to custom fields?
Only problem is, “property tables” in relational databases tend to bloat up faster than you can say “Sally Struthers”, while at the sametime foregoing any of the benefits of relational databases – how useful is it to search or index a property table?

I believe it is time that we stopped sticking square pegs in round holes in the IT industry, stopped assuming that a relational database is necessary for exactly everything we do – more often than not a relational database will only bring on unnecessary complexity, unneeded performance and scalability bottlenecks (especially when not used for relational data), and overhead in the form of impedance mismatches.

There really is no reason to always stick to a relational database for all your data storage needs, there are perfectly good alternate solutions:

• Filesystems and web file systems such as Amazon S3 for storing files and simple data.
• Memory (RAM) to store transient data such as web session data.
• Object databases are perfect for storing, well, objects.
• Document databases (such as CouchDB) for storing documents and data with more free-form schemas, such as data with a lot of custom fields.

There is no reason to use a database as a hammer to every problem in the software space, there are more than enough other more appropriate storage options available in the toolbox, if we are just willing to have a look and not see every problem as a nail.

The “Keep It Simple, Stupid” (KISS) principle is invoked quite often, especially in the Agile world, however I’ve found most projects actually only pay lip service to the KISS principle (pun intended).

The Evils of an “assumed” application stack
The most common case is that people have an assumed application stack – they “know” before they start that they will use some sort of MVC framework, Spring, Hibernate, deploy to Tomcat, use MySQL as a database, add in a few validation and templating frameworks for good measure, and maybe use some of Springs flashier features while your at it.

Sure, this is probably better than the J2EE servers and EJB’s of days past, but do you really, really need all of this? First of all, starting out small, do you really need Spring to tie your app together? How about just instantiating objects? A lot of the time you’re just pushing compile time dependencies into becoming runtime dependencies but with no added benefit and the added drawback of harder to debug code (yes, a Spring xml config is code).

Second of all, unless your application is some sort of trading or payment system where transactionality is of the utmost importance. Do you REALLY, really need a relational database? Are you sure you couldn’t just use in-memory objects, files on disk, Amazon S3, CouchDB or something similar?
Even if you do need a relational database, do you really need to push all the data into it? Will other means of storage, or none at all do just as well?

Your “assumed application stack” is the first place where complexity starts creeping into your application, almost on the first day. If you critically challenge your assumptions, you might find that you don’t actually need all the bells and whistles you are throwing in there.

API’s that sing, dance and make coffee
The second case, and most often the place where projects start to really derail is API design and following functionality design – people start adding bells and whistles to code others will use, assuming they know what they want to do with the API’s. Don’t. Just do the bare minimum that works.

Ironically enough, the most extensible, flexible API’s are usually the ones that are minimalistic and do as little as possible. API’s that try to cater for every eventuality and predict what people want to do and how they will use it usually end up a convoluted mess, inflexible to the actual needs of users.

The principle of doing the absolute bare minimum that works, and not trying to second guess future uses works remarkably well.

So the next time you invoke “Keep It Simple Stupid”, have a serious think about what it actually means. Are you actually keeping it simple, “stupid”?