Open Source and IBM

Martin Fowler's review of JAOO2005 includes this blurb:

"On panels 'Bedarra' Dave Thomas and Brian Barry said that they believed the current spate of Open Source development was unsustainable. Much support for open source is funded by large companies, IBM's support for Eclipse is a long one. They felt that this support wouldn't last, if so there's likely to be quite a collapse in open source activity. (I'll stay silent on this question, I prefer to avoid trying to predict the future.)"

All I can say is WHAT!?!? Someone doesn't understand IBM's business model. They are not a products company, they make their money on services. Therefore, they want to sell things based on thier services expertise. By making products open source, they eliminate the competitive advantages of their opposition. That allows them to compete on an even keel, services vs services. If anything, IBM wants MORE open source products so that they can sell more integration services. Sheesh!

The Value of Domain Knowledge

I recently gave a talk to the computer science department at my undergraduate university. I was trying to inform them about the state of the industry and give them a little heads up on what they were getting themselves into. One thing that I think they found interesting was my statement that we are merely problem solvers. We are like astronomers and computers are our telescopes. Obviously, being able to use a telescope is important, but our ability to solve problems is our most valuable asset. Computer Scientists have replaced mathematicians as the problem solvers of choice. While mathematicians have their formulas and proofs, computer scientists have the ability to solve problems with brute force. Being half academic, I pine more than wonder at our barbaric problem solving abilities, but my other half enjoys the "get it done" mentality.

As a problem solver, one of our most valuable assets is domain knowledge. Any newly minted B.S.C.S. can turn specs into code, but to be able to have empathy for the user and understand the domain comes only with years of experience. When you ask the user what he or she wants and then you come up with more items than the user does, you have achieved domain expertise. It is akin to the astronomer who can predict the number and size of planets based on the wobble of a star. To a company, this is the most valuable an employee can get. Not only can they contribute to a company by "tuning the telescope", they can also help analyze the results and even help construct a telescope that better measures what they wish to measure.

Where does this leave consultants? Well, there are two different kinds of consultants, and it effects each differently. Some consultants make thier living off of training others. Technology changes at such a rapid pace that schools cannot provide adequate training for everything that you might ever see. These consultants work hard to stay abreast of best practices and then transfer their knowledge to those who hire them. It is similar to teaching earth-bound astronomers how to operate the hubble. Obviously, they never envisioned the hubble when they were in school, so that new knowledge has to be imparted to them in some manner. This is a valuable service, and we should think of it as an extension of school rather than as a consultant.

The other form of consultant is an expert telescope user. This consultant is paid to be very good at using telescopes. He cannot tell what he is looking at, but the telescope is guaranteed to take the best pictures possible. Obviously, this consultant needs a lot of hand holding. In many cases, it is easier to just tune the telescope yourself; however, there are times when the person reading the pictures no longer knows how to use the telescope. This position has a value, but it is small compared to the other two positions I described.

So, as you evaluate where you fit in on the spectrum, see if you provide domain knowledge, education, or just an extra hand. If it is the latter, don't be surpised to see your hand replaced by a cheaper one. If it is the former, and you are being replaced, then you have to seriously wonder about the health of the company. And if you are in the middle, enjoy the moment, but keep learning for the future.

Dilbert Blog

Here it is, Scott Adam's Dilbert Blog.

Reuse

Reuse is a good thing right? Give the option to reuse good code or write your own, you would always pick reuse. We've heard tales of horrible programmers and their NIH (Not Invented Here) syndrome and we're not like those guys. We want to leave our pride at the door and hold up the shining shield of reuse and the burning sword of standardization.

Not so fast.

Reuse, like ANYTHING ELSE, has its tradeoffs. On the one hand, you get "free code". On the other hand, its not free because you have to learn how to use it, debug it, and write integration code to get it into your project. On the one hand, you get "free upgrades" as a separate development team makes upgrades and enhancements. On the other hand, you suseptible to changing interfaces, newly introduced bugs, and silent but deadly logic changes. You are dependent on that code and its uncertain future.

Joel defends NIH for good reason. His basic premise is something I've been saying for quite some time: software development is the practice of managing dependencies and the dependencies that are easiest to manage are those that are not there. Just like in life, the more dependencies you have, the less agile you are (those with children: how easy is it to do something spontaneously?) - and in the tech industry agility is everything.

Often the development cost of the product increases when you eliminate dependencies because of some duplication; however, the ability to improve the product quickly also increases and that will gain enough income to overcome the incresed development costs. Now, don't get me wrong, you shouldn't go rewrite Windows in order to not be dependant on it; there is something to be said for interoperability as well. However, if it is core to what you do or it plays a vital role in your product then you should own it and it should have a one-to-one dependency chain between you and it. The cost will be well worth the rewards.

Large Company Dilemma

Once your tech company reaches a certain size, it has a dilemma on its hands. Usually, the problem is that it cannot increase its profitability without taking on more people. However, the people available to take on are not the same calibur as the people already on board. Therefore, the company can either refuse to take on additional hands and stagnate or take on average employees and eventually capsize. There appears to be no other outcome. The difficulty lies in taking average employees and making them great, when I'm not sure that is possible. Like turning lead into gold, it is just not within our abilities, today. Of the two options, capsizing seems to lead to the most profit and the capsizing doesn't necessarily mean the downfall of the business. Instead, it could just mean massive layoffs followed by restructuring as was the case with IBM and Apple. However, it seems to me that there should be a way to fill the traditional product units with the new mediocre guys, because their profit has been extracted and then spin off a new company with the masterminds, letting them focus on creating "The Next Big Thing." Just a thought...

Double Entry Bookkeeping

I don't remember if I mentioned this on my blog, or someone else's, but I view TDD as double entry bookkeeping. Apparently, Uncle Bob does, too.

Update: it was on my blog.

The 4th Quarter

I've been recently wondering if always having to win the game in the 4th quarter makes you stronger or weaker. When you have to come from behind and fight for your survival, does it give you mental toughness or does it just drain you, emotionally? What happens when you finally lose, is it just another loss, or is it the proverbial straw that breaks the camel's back? How much can you take when it is always on the line? Interesting questions, no answers. Keep coming back for updates.

The trip

So, you're going on a trip from San Diego to Buffalo and you've decided to travel by automobile. You now have two popular options: drive your own car or ride in someone else's. For the moment, we're going to ignore driving someone else's car or riding while someone else drives yours.

If you decide to drive, you get to pick what car you take. You can take the gas guzzling SUV or the environmentally friendly hybrid. You also get to choose who goes with you. I hope you choose who goes with you for good reasons. You might pick Bob because he is friendly and good company. You might pick Ann because she is great with a map. You might pick Fred because you know he doesn't have to stop at a bathroom every 30 miles. Finally, you might pick Jill because she offered to pay for the gas if she could tag along. One thought is to pick people who want to go in the same direction as you. Perhaps they don't want to go to Buffalo, but going to Seattle or Tampa Bay would probably be a little out of the way.

If you decide to ride, your options are different. First, you need to find someone who can take you. It could be that you have to get on a greyhound bus: they are cheap, fast, fairly safe, and if it breaks down you don't have to worry about fixing it. Or, you might have a friend or acquaintance driving their own car and they invited you to come along. Often, the invitation process is stressful and intrusive, but once that is over with the ride can be quite nice. There are additional things to consider, things over which you have no control. For instance, who are they taking with them? Are they taking Reggie, the loud obnoxious guy you can't stand, or are they taking Gina, the cute secretary from across the street? These decisions can definitely affect whether or not you choose to ride. Of course it could be that you don't own a car and Reggie is your only hope, but we try not to be in that situation, don't we. We brush up on our map reading skills, learn how to control our bladder, and try to save enough money to help buy gas. Then again, it could be that your best friend is going to Columbia and has asked you to come along. Yes, he is your best friend, no you don't have your own car; however, going to Columbia (the country) does not help in your quest to get to Buffalo, so it is best to avoid that trip. It also helps to examine the car you will be riding in. Do you think it can get to Buffalo? Are there already too many people on board? Has the driver engaged in preventative maintenance? It could be that you just hop in the first car available and blindly wish for good fortune, but that inevitably leads to disaster. The best thing to do is to know yourself and choose the transportation method that is right for you.