Sunday, December 17, 2006

Generalization and Specialization

I have been reading "My Job Went to India... (and all I got was this lousy book)" by Chad Fowler. I'm still in the middle of it, but a couple of sections really resonated and I wanted to jot some thoughts down while they were fresh in my mind. It is probably worth mentioning for those not familiar with the book that it is not really a criticism of India or of outsourcing in general, but rather, a pragmatic discussion of how to survive in the midst of the current trend to outsource technical work. Fowler presents his thoughts on what a person can do to keep their job domestic when so many positions are leaving the country.

A couple of his ideas are contradictory, yet complimentary. He argues that a developer should decide to be a generalist or a specialist. He compares the specialist to an assembly line worker on a mass production line. The generalist, on the other hand, is the proverbial "Jack of All Trades, Master of None". I like that Fowler tries to dispel the negative connotation surrounding this label. In Fowler's opinion, either path can lead to better protection of your job.

The generalist is able to pick up the odds and ends and minutiae left behind in the wake of layoffs or outsourcing. He argues that it is important for the generalist to understand to some level the product at both a business and technical level. At the product level, understand the customer needs and business case for the product. At the technical level, not only should you understand the code used to realize the product, but also the architecture, test strategy, and deployment process. The generalist should also be careful not to fixate on specific technologies, e.g., code versus database, Java versus C#, etc.

A specialist can make his or her self safe in a different way. This is accomplished by understanding an area of technology to a depth that qualifies this person as a guru. By doing so, the developer becomes the indispensable resource of last resort, turned to when the really hard technical issue crops up that the rest of the team can't resolve. Fowler is quick to point out that this is a difficult state to attain. One example he uses is an interview question, "How would you write a program, in pure Java, that would crash the JVM?" He argues that unless you understand the internal workings of the JVM (which would include the threading model, memory management, and instruction generation), you aren't a Java specialist.

As an aside, I don't consider myself to be a Java specialist, but my first thought was to exhaust memory, but I am sure there are faster ways to crash the JVM.

While he didn't come right out and say it, I got the feeling that Fowler sees generalization versus specialization as an either/or proposition and that he maybe leans a bit towards favoring generalization. While I concur that generalization is a better survival strategy, I think there is room in the generalist’s repertoire for some degree of specialization. In my mind, a melding of the two ideas is very compelling.

I consider myself to be a generalist. I am a degreed electrical engineer. I have experience with digital electronics. I spent the first four years of my career coding in assembly for an embedded real-time system. I also wrote real-time firmware in C and C++. I have written graphical applications for Windows and the original MacOS. I am currently developing middleware apps in Java. I also have experience with scripting languages such as PERL, TCL, and Bash. I wrote some SQL and am currently learning the Hibernate ORM utility. Next up is Groovy. The list of things to learn is very long and is growing faster than there is time in the day.

I don't mention this to toot my own horn, but to support my hypothesis that I am a generalist. But I am also a specialist, albeit what I will term an opportunistic, short term specialist. Invariably, during certain stages of a project, I wind up learning something to a detail that meets Fowler's definition of a specialist. The area of the specialty varies from project to project and because of this variability, the half-life of my "specialist" qualification is short in duration (on the order of 1-2 years). For example, in the mid-90's, while working in the test and measurement industry, I became an expert on the IEEE 488.2 and SCPI command sets for instrument command and control. I knew the vagaries of the standards and what requirements needed the most work in the code. Ten years later, the details escape me, but at the time, when a question was raised about these protocols, folks came to me. The same has occurred in other industries, including understanding drug interaction for IV compounding, VME and VXI bus protocols, ISDN signaling (LAPD and Q.921), and currently, I am immersing myself in the agile methodology, SCRUM. In the spirit of "use it or lose it", when I move on to other projects, the details get fuzzy, but I always try to adopt at least one topic to focus on and embrace in a detailed sense.

The side-benefit of this strategy is that even when the details fade, much of what I learn can still be applied in a general fashion. Which supports my initial statement that I am a generalist. In summary, as a generalist, sometime specialist, I can attest to Fowler's thesis that developers who adopt these strategies maximize their chances of staying gainfully employed. It has worked for me.

Sunday, December 03, 2006

The Open Source Community... Loony or Enlightened?

I attended the Lightweight Java seminar with a colleague last week. The seminar was hosted by Virtuas. Virtuas is a services company specializing in open source software. Their stated mission is to assist their clients in becoming self-sufficient users of open-source software. More on this is a minute, but first a quick overview of the seminar itself, which was composed of four talks.

The first talk covered the Java Persistence Architecture, or JPA, which is part of EJB3. A simple description of JPA is annotation support for persistent objects. The JPA is defined in JSR 220 and represents an attempt to simplify J2EE. Since I'm not an "enterprisey" guy, I can't discuss how well it addresses this need. I do have some experience with JPA, as it is implemented in Hibernate. I will be giving a talk of my own on JPA use with Hibernate in January at the Boulder JUG. I will be focusing on the use of annotations in Hibernate without the use of XML configuration, so definately an anti-enterprise spin. I will post the preso after the JUG. At this talk, the speaker had a great example of persistence using a snake object that eats rabbit objects. Call me twisted, but I liked it!

The second talk covered Spring 2.0. Spring, in keeping with the "lightweight" theme of the seminar, provides a lightweight container environment that simplifies the use of other open source components including Hibernate, AOP, web services, LDAP, ACEGI security, an MVC controller, and more. Of course, "simple" is relative. In the case of Spring, this means that while you write less code, you substitute large XML configuration files. Anymore, every time I am told "less code through configuration", I feel like I am at a timeshare sales presentation. Caveat emptor! Even with the configuration overhead, I do think that Spring brings a lot to the table. It is definitely on the list of things to get up to speed on.

The third talk covered AJAX and JSF along with the DOJO library (word of advice, 4.0 is buggy, us 3.1 for now). These are tools that make some great web interfaces. Added to the list.

Finally, a talk on the AppFuse 2.0 framework. This framework ties all of the other pieces together when developing web apps. Since I don't do much web development at this point, some of the talk was lost on me. Probably the biggest take from the talk is that Maven is getting bigger and is now on the LOTTD (yeah, it's a long list).

Prior to the seminar, we weren't sure what to expect. We halfway expected to be subjected to a non-stop flood of markitecture. On top of that, the weather was really crappy. We really debated attending. Fortunately, we decided to go. It was definitely worth braving the weather. When we first arrived, we found that we were getting an amazing "goodie bag", which included three great technical books (on Java, Spring, and Eclipse) and a nice day-planner. The goodies were courtesy of SourceBeat. Want to impress a geek? Give them tech books! And it just got better from there. After a very short (less than 10 minutes) introduction of the company, they jumped right into the presos. Not only no markitecture, Virtuas took the soft sell to the extreme... almost a no sell? The great goodies, excellent talks, and lack of sales pressure all contributed to the inspiration of this blogs title. Can a company, which depends upon revenue from consulting on products that are free, be successful when using a marketing tool such as this seminar? I hope so.

As a way to say thanks, I started thinking about what I could do to help them. I'm not really in a position right now where I need their help, but I will keep them in mind for future issues. In the meantime, I am hoping that by blogging about them, I can help is some small way to get the word out about this enlightened (as opposed to loony) company.