Comparing Stats on this blog Feb & July 2008

I've been keeping stats on this blog since Febuary 1st of 2008. Here's some numbers. Don't know if they are good, bad, or whatever.

February hits: 1,503
July hits:     2,681

So I've not yet doubled my traffic in the last six months. What do those numbers over the last six months look like in total?

13,961 Visits
10,954 Absolute Unique Visitors
17,323 Pageviews
1.24 Average Pageviews
00:01:00 Time on Site
85.76% Bounce Rate
78.40% New Visits

... so most folks just bop through here and on their merry way. only about 15% are getting anything from their visit. I wonder what the average visitor's browser looks like? Top five browsers are a small surprise...

1. Firefox / Windows            49.86%  
2. Internet Explorer / Windows  20.06%  
3. Firefox / Linux              13.37%  
4. Firefox / Macintosh          6.88%  
5. Safari / Macintosh           4.61%

Firefox trumps explorer. But then consider the audience... programmers... yeah, I guess that makes sense. Interestingly 70% are Windows users, 13% are on Linux, and about 10% are on Macintosh. That's a bit surprising to see Linux rank higher than Mac.

I won't try and break down the search engine stats here but what I gather is that most visitors to this page are getting here through google or yahoo. Surprisingly, the most used key words are "grails portlet" I'm very happy to see GRAILS-254 coming along. Check out Lee Butts' documentation of his work.

Ironically, I never did follow through on a Grails Portlet because we dropped the use of Portlets in our organization. It would not have paid off for us to do portlet development until we had a much larger constellation of projects. I may have to revisit portlet work in Grails in the coming months judging from this demand.

I'm not a bit shocked that my more technical Grails articles enjoy the most readership so I plan on ending my indulgence of more abstract topics and getting down some serious Grails related business. I've just shipped a major Grails project that represents six months of work so I should be able to dig deep into that experience for a few posts.

What I'd love to hear either formally or on the side is how these numbers stack up to other blogs. Are these good numbers? Are they bad? I'm hanging them out there for everyone to see (or laugh at) because I have no delusions about being a well read blog and no reason to hide them. So I've offered first. You go next.

Why do you read this blog? Apparently about 3,000 of you come back here from time to time. How can I focus my topics to help you better? What would you like to ask me about my last year working in Grails full time? Any pointers from "professional" bloggers will be welcome.

Software waste

Consider the plight of Microsoft and their rampant success that has also sown the seeds of their current woes. Also consider the plight of the BBC and their strange web platforms. And, I think we can start to see the inside of a very real recurring problem that date back at least to Fred Brooks Jr. and probably point back to problems that have plagued all engineering projects that require much management over-head.

Computers do a great job of covering up wasted labor. That's because they can crunch through stupidity like nobody's business. You have to wonder if management could actually see the product being built if they would take such a stance (both at Microsoft and at BBC).

It turns out that being insular in your development practices means you get to be "the old man on the mountain" and your shop turns into something quite unique... most of the time in a very bad way. The ideas of DRY, open source, and code reuse are ideas that we hold onto in the great wide community of developers to keep us from wandering down dead-end trails. The results of which are utter disasters unless you are Microsoft or the BBC which are both big enough to just absorb the loss.

My message to you is to get out there and get some of your sacred cows challenged. Learn how to defend your choices and your technical abilities or learn to change them. Do some open-source work. Stop making stupid rules to limit the creative talent you employ. Get out there and learn from others.

Code Size and the Cognitive Gordian Knot

The size of a code base is not the worst enemy of code.

My personal experiences with code bases large and small have given me the insight to realize that size of code is a terrible enemy but not our worst enemy. Our worst enemy is stupidity. Well, not out right stupidity but what I call the cognitive Gordian knot.

The larger a code base is the more material there is to create a knot. The smaller, the less material there is to create a mess with. So there is beauty in the small. I have been arguing for the decomposition of large projects into small reusable code units for most of my career.

Yet, I've seen examples at Coding Horror and The Daily WTF that show in a scant few lines some of the most impressive inability to think I have ever seen. These examples are not necessarily what we would consider mind numbingly, guffawingly, powerfully brutish idiocy but subtle brain warping WTF? These are the thought-knots we can't untie like that knot of legend the Gordian knot.

During my time over seas I have worked on code bases whose ages were measured in decades and sizes estimated in rough fractions of millions of lines. Code bases of this size are surely incomprehensible but the best can have inner structure that can be navigated and internal API that can be understood. The reader of this kind of code doesn't need to know what exactly each call does but only understand the local code and some specific libraries to work on it.

And then later in my career... oh the irony... I maintained a code base of a scant few hundred thousand lines of code whose internal structure shifted upon itself every few lines. Every few hundred lines a new API, a new convention, a re-written API, a half-refactor, a violation of another API. And so on the insanity folded over and over upon itself like a Lewis Caroll narrative without any beautiful onomatopoeia. All of it written by the same person over the course of five years.

Instead of a crystalline structure found in those majestic and old code bases whose patterns fold and unfold like a fractal thus leading the maintainer to an understanding of the whole from only a part... this newer... this smaller... this uglier code base contained no song and no resonance that my mind could fix upon. Instead it was a tangle of swamp weed coated in a toxic sludge that defied understanding and like "Alexander the great and the Gordian knot" I saw no other answer to my problems other than to cut it asunder. Bust it up, break it apart, make it small again.

No, I know better, size is not what kills code. It is the Gordian knot of superficial complexity that kills code. Instead of a crystalline pattern or an enforced internal structure the code is allowed to grow untamed. The key to long life in code is pulling out and separating concerns into libraries and frameworks.

You could argue this tactic constitutes removing some code from the main code base and creating small supporting projects that fit together to create a whole. You'd be right. That's what it is. That is what I mean by saying fractal, crystalline, or internally disciplined. The supporting libraries may be internal to the project but they may constitute sub-projects they divide and conquer the problems and keep the material from building to the point that it can accidentally tie itself in a knot.

You could achieve this using MVC, Services, or libraries. I've seen Domain Driven Designs and Spring annotations to enforce SoC that would work well. You could say this is how Linux and GNU work together to create a full operating system. You could say that is code reuse and proper object orientation. You could say this the weapon we have in the mix-in and dynamic language.

Whatever you call it. It makes code easier to understand because it has a logical structure and what I call a resonance or song. It means you can see part of a code base, understand it, and ignore the other concerns to focus on your particular problem.

If you can dive into one section of code and comprehend it without having to comprehend the whole thing then I say you have a good code base no matter how big or how small it is. The goal is to keep the knotty beast at bay for as long as possible using every trick we have.

Interoperability is the key to success

I just read the We have lost control post by Reg Braithwaite that's been making the rounds of the blog-o-sphere. Basically, modern IT departments compete directly with the internet. We have to. It's the 21st century. That's because...

Our users are being exposed to applications we don’t control. And it messes things up.

It means that our end users have used the internet and if our programs don't measure up they know it. You can't hide it! They know! Braithwaite tells us this lovely story about working on a CRM for his mum:

For example, my Mother uses Skype to talk to her friends. She thinks it’s normal to see all of your voice mail messages in a list on the screen. If I tried to give her a CRM application for managing contacts, the very first question she would ask would be, “Why can’t I listen to all of the voice mails from that contact in the application?”

Do you think she would have patience for my explanation that the company’s phone systems are complex and proprietary and that we can’t install Asterix just for her? She would grab me by the ear and drag me to my desk to get cracking on it!

In other words if you ship a CRM today that can't interoperate with a phone system... or your phone system can't interoperate with a CRM... your in house CRM will not measure up to the internet based competition... Skype.

And is the user wrong to expect a Skype-like experience? Should the IT department tell them to go suck an egg? I don't think that will fly.

Long story short modern IT departments will have to provide in-house mash-ups of services to be able to provide an end user experience that can compete with the wild and wooly internet.

BTW: I now believe that the Grails Searchable Plugin will change my life. Even though I haven't used it yet. Because I can see how full text search wins and how that plugin can single handedly enable search for all my projects. Yes... the computing world is about to change... again. Hold on for the barrel roll.

The humor of Engineers

From the wikipedia entry on Portal the video game:

"at the beginning of the Portal development process, we sat down as a group to decide what philosopher or school of philosophy our game would be based on. That was followed by about fifteen minutes of silence and then someone mentioned that a lot of people like cake."

I wish I worked in a team that had conversations like that. Oh... wait... I do.

Some advice from a smart guy

"Any fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction."
-- Albert Einstein

Make your software small, simple, and powerful.

Code Addicts in Java Land

Some one just sent me this Billy Hollis video. Billy asks us if we are "Code Heads" and although his solution is Microsoft based, it's and entertaining talk just the same. It is why we have 1.2 billion frameworks (a slight exaggeration) in the Java code space. Developers need frameworks and developers like writing them. The problem is developers don't seem to like using the other guy's framework.

Microsoft has the benefit of being "the one" and can dictate the community's direction. Few vendors have that luxury. That's one reason why Microsoft shops have an easier time making up their minds... they have no real choice.

Java shops have a myriad of choices and can decide to go any number of routes. You could go application server specific, Java standards specific, or with an open source framework. You could choose to write in a dynamic language on the JVM or in plain old Java.

The trick is to recognize when you can leverage the framework and to actually do it. Don't write the code for the sake of writing code. Use the tools in your frameworks for what they are good at.

Sipping Googleccinos

But then, while you’re sitting on your googlechair in the googleplex sipping googleccinos and feeling smuggy smug smug smug, new versions of the browsers come out that support cached, compiled JavaScript. And suddenly NewSDK is really fast. And Paul Graham gives them another 6000 boxes of instant noodles to eat, so they stay in business another three years perfecting things.

- Joel On Software

Okay, that's about the funniest thing I've read in a month. Kudos Joel.

Engineering for the Web

"What ever happened to Web engineering?"

"The problem is, strictly separating designers from developers has resulted in a Web built by people frightfully unaware of the standards and technologies required to make it go. Most Web pages today extend well beyond the limited scope of HTML, and a good many of them bring together a "pure" programming language like Java or C++ (you know, real code with control structures and variables and stuff) with healthy chunks of JavaScript, PHP, HTML, CSS, and oh, don't forget, XML."

This just feeds my assertion that the dot-com boom was the worst thing to happen to software engineering practice in computer history. The bust was harrowing and the good and bad alike were cut down, but, the boom is what fostered the legacy of bad practice and unrealistic expectations that we have to fight today.

The new movement to introduce engineering principles back into web development shops should be unnecessary.

Getting the right start

Starting out right is incredibly important. Someone once said, "choose your parents wisely." In software development I think that we really do have a chance at choosing our proverbial parents. Choose who you learn from wisely.

Depending on what your goals are pick mentors and teachers that exemplify those goals in their careers. The way these people think will alter the way you perceive the shape of what software is and how it should be made. The way you think about this things will yield either success or doom you to failure.

If I could get a "do over" for the last year and a half I would have started with getting to know who were the big thinkers in the land of Java. I would have spent some time reading their books. I would have avoided marketing fluff and I would have looked at real world experiences. I would have talked to real Java developers.

In short I wish I could have started my journey from C & Perl programmer to Java programmer by attending a conference such as No Fluff Just Stuff. Not because it would have eliminated any confusion... but because I would have learned what other real life Java developers think. How do real life Java developers solve these problems?

It would have made all the difference in the world. Too many developers suffer from what I call "old man on the mountain" syndrome. Instead of living the life of a hermit learning only from books, spend some time in the community learning from others.

A year with Java 5 EE

I've spent the last year with Java 5 Enterprise Edition betas and I'm going to talk about my experiences with the Java environment as a relative newcomer to the Java landscape. My background is in C/C++ System V programming on Linux, Solaris, and Irix systems. It has been a hard year but one that I'm thankful for. I've learned a lot about how Service Oriented Architectures go together, why they work, and why they fail.