It was the last straw. Any more posts by James Altucher or Aaron Levie and I was going to blow my brains out. Not that they are particularly bad writers, but TechCrunch has become overgrown with these guest contributors and uninteresting posts. I needed a change.

It got so bad that I started to track down old TechCrunch writers to see if they are doing any good writing these days. Now, it may not seem so significant to you, but when I read this from MG Siegler, I think it is on another level completely from these recent TechCrunch posts by Altucher and Levie. To me, MG’s piece is wonderfully opinionated, tells a story and shows some insight. It is long, but I read every word.

So when I read about Pando Daily I knew I wanted to try to cut the cord with TechCrunch.

I’ve been involved in projects of all sizes. My focus lately has been on smaller prototyping and proof of concept demonstrations with as little as one or two people, but I’ve spent years on large projects with hundreds of engineers.

There is a problem that shows up again and again in a wide range of projects when you get above a certain size. The problem is premature parallelization, which I touched on in the last post about pair achitecture. The surprising thing to me is that I’ve seen it be a problem with just half a dozen people.

The problem comes about primarily from a pressure to execute. If you have a team of architects, you want them architecting. If you have a team of developers, you want them developing. When a new project or feature comes along, there is a drive to get everybody engaged as quickly as possible. The thinking seems to be that, by engaging everyone as soon as possible, the work starts sooner and therefore the work will get done sooner as well. In a way, it is like a horse race - all the groups lined up in their starting gates chomping at the bit in anticipation of the starting gun. What gets lost some times is the up-front collaboration work required to make sure everyone is really pointed in the same direction and everyone knows where the finish line is.

I’ve seen pairing work in areas other than programming. At Lockheed, we did “pair analysis” and I had my architecture team in Motorola try out “pair architecture”. The reasons are largely similar to that of pair programming, but there were some unique benefits as well.

First off, I have to admit that neither of these were strict pairing in the sense of working together on a work product at the same time. And in both cases, the team was made up of people with similar experience levels, but with different knowledge areas.

At its heart, I think software development is a communications business. In a nutshell, the goal of software development is to communicate user needs into computer processor instructions. That’s really all there is to it.

Now when you look at that communication path, there are quite a number of different skills needed to take the thoughts and desires of some population and make machine instructions out of them. This can be extra tricky for a revolutionary product or service where that user population doesn’t even exist yet and won’t exist until the instructions have been written and released to the world.

Why use Annotations?

Annotations are a declarative way to extend class functionality. Other ways of extending class functionality are through inheritance, composition, the use of mixins or extra-language descriptions such as Aspect-Oriented Programming or other declarative markup. The tradeoff between these approaches is probably most important when designing frameworks. There has been a gradual shift away from using inheritance as the primary mechanism for extending frameworks since the added coupling to the framework is frequently a maintenance headache. In Java, the term POJO (plain old java object) is used to indicate a framework which can add functionality to plain java objects which do not have to extend or inherit from classes provided by the framework. Spring and Hibernate are popular examples of such frameworks. Hibernate is a object-relational-mapping framework which allows extension both through extra-language declarative markup (XML configuration files defining the mapping) and through annotations (both standard JSR-317 Java Persistence API annotations and proprietary ones).

The short answer is you should use annotations if you want to allow developers to add functionality to their code without changing the inheritance structure of their class tree. It is also popular to do so with external XML markup, but (for Java at least) development environments currently have better support for annotations. Java annotations are parsed in Eclipse and so the editor provides direct feedback when syntax errors exist. Annotations are also supported in refactorings, meaning changes to annotation classes or other class references will be automatically updated in the whole code base. This is not currently true for XML mappings - changes must be manually synchronized between the java code base and xml markup files. The benefit of an XML approach is that it does not require any changes to the original source code. This further reduces dependencies on the framework and also minimizes clutter in the classes that numerous annotations can sometimes bring.

The examples here are drawn from a framework based largely on JSR-311 Java API for RESTful Web Services.