How large is your toolbox?

I have always told myself and anyone asking my choice of being a computer science generalist is a choice made with utter awareness. There are basically two paths you can take in the IT industry if you like to work close to tech. One is that of the specialist. The other is the generalist. 

Specialists are dedicated professionals with extreme skills and a burning desire to continously sharpen themselves in their field of work. I have met many of them, and they are all fantastic people with true passion whether they work as DBAs, .NET devs, Integration developers or business intelligence people – they all share the common need of perfection.  

Generalists as myself on the other hand tend to work in the cross-over-field making use of multiple technologies at the same time without really mastering any of them. It can be a somewhat frustating situation since you really need to rely upon the experts, the specialists, to solve the more tricky matters, sometimes leaving a sour feeling of never being able to accomplish things on your own.

Although specialists are much sought after resources in a competitive world, I would never trade my place with anyone of them. That is mainly because of two things.

First of all, generalists are survivors. We don’t let any major shifts in technology affect us. Our mission is to bring different tech togehter, maximizing the overall use. From our perspective, every tech part is interchangeable. That makes us a lot less vulnerable on the market. Technological shifts are extremely common today and occurs ever more frequently.

Secondly, the toolbox of a generalist are grand. More so than that of a specialist. Specialists carry shiny, golden hammers, and they sure know how to use them, but when the mission to saw the log into two halves arrives they are lost.Believe me, I have met a lot of developers and architects with the agenda to solve each and every business problem with their specific tool. “Hey, let’s build the ERP in BizTalk!”, “Wow, we could really create this webshop using nothing but Sharepoint!”, “Modeling an invoice you say? I’d prefer to do that in T-SQL”. In fact, I know some of my friends and colleagues from time to time would say I myself act that way, but that is not my case. What they all tend do miss is the drivers behind my vocals for a technology or another. When I speak warmly about BizTalk, it is when we face heavy integration. When I speak warmly about Azure, it is when we face scalability issues. When I speak warmly about services, it is when we need to break free of the monolith.

Ironically, these misinterpretations are often spoken by people on the more specialist side of the scale. That said, the ecossytem of IT needs both specialists and generalists. We would not survive without one Another. But in that world, we also need to learn how to live in harmony.

The importance of ALM

Application Lifecycle Management. I suspect this is the first post in an upcoming series about my everyday life as a product manager and the center of my universe, namely Microsoft Team Foundation Server. My TFS pal is to me what an ERP would be to corporate controllers, CFO or CEO. I would even go so far as to say the ERP for us as a Product development company is well behind the ALM system in a matter of importance.

The first thing to understand is the difference between delivery of “solutions”and products. To me a solution is exactly that. A solution to a particular business problem or need. A solution solves one problem, and does so well, but its main characteristic is that it solves one or at least very few problems, and perhaps in such a tailored way  that it would be of little use trying to apply it elsewhere.

A product is something of a meta-solution. A product solves further generic problems, more business problems or fullfills more needs. But most important, it has a life. And a Death. New requirements arise to be incorporated in the frames that make up the product. Old requirements change and therefore the product needs to change. At some point the technology stack the product is built on has been surpassed by more innovative ways of doing things, or the businesses making use of the product have changed so much the product must be laid to rest and replaced by something new.

To respond to those needs and ever changing requirements without having to build a new solution for each change is what product development is all about. Doing so and also keeping the time to market short and the quality in the product high is virtually impossible without decent tooling. The tool for doing this in my agile Environment is TFS.

In the next few posts I will show some neat things in TFS 2013 and how it affects my team, my work as PM and what the platform has done for us regarding product quality.