Last night on American Idol, Stevie Wonder referred to "Chicken Little"'s voice as "interesting". This was the kiss of death. In other words, Stevie was implying that his voice was horrible and he had nothing better to say. For me, in school, the worst thing to hear was not that I was interesting, but that I was smart.
When you're smart, it often happens that it is your only attribute. No one notices anything else. You're labeled as "the smart kid". Sometimes, you get worse monikors, but we won't disucss those :-) I spent most of my childhood and adult life hiding from that term. In school, I never wanted to tell others what I made on my tests. I never announced my grades like others did. My goal was to blend in completely. In my adult life, I never bragged on my degrees or how fast I got them. At my previous workplace, the only way most people knew I had a Ph.D. was that someone else told them. I never announced it or put it in my email signature or anything else. When I see people with a Ph.D. at the end of their name, I laugh inwardly. "Why would someone want to draw that attention to themselves?" I would ask. When I taught at the college level, I had my students call me by my first name.
Deep down, this was only to avoid the "smart" label. I hated it so much from my childhood that I would have done anything to avoid being labeled with it. But my new year's resolution is acceptance. Last week, I dug my Ph.D. degree out of a box in my office and put it up in my cube. It's a first step.
Wednesday, March 15, 2006
Sunday, March 05, 2006
ALAR Conference
Long time, no post. However, I'm back from the ALAR Conference and I have a little time, so I'll post. Hopefully, this won't be the last for a while. The ALAR Conference is a data engineering and grid computing conference put on by the Acxiom Laborator for Applied Research. There were a number of great presentations there. I had a paper accepted into the conference, so I got to speak as well.
I brought two important things away from the conference. The first is that I really miss research, especially applied research. I'm going to have to seriously consider how to inject research into my current job, or move on to something new. Research has been a part of my life for so long. In many ways, it defines who I am.
The second thing I took away from the conference was the need to examine distributed game programming. It appears to me that they have some insight on how to handle a massive number of incoming transactions. Sure, they cheat a little, but it might teach us how to cheat in similar or different ways. For instance, they use "realms" to limit the number of players on a single server. Data engineers can also mimic that by the use of a good, pre-defined partition key. They also allow lossy transactions. Since you're going to be sending another transaction in the next milisecond, it's ok if we drop one. I don't know how to replicate that ability with data, but I'm willing to investigate the possibility.
Lastly, it was a great chance to meet up with old friends both from the Corporate world and from the Academic world. I was amazed at how many people I actually knew there.
Well, until next time...
I brought two important things away from the conference. The first is that I really miss research, especially applied research. I'm going to have to seriously consider how to inject research into my current job, or move on to something new. Research has been a part of my life for so long. In many ways, it defines who I am.
The second thing I took away from the conference was the need to examine distributed game programming. It appears to me that they have some insight on how to handle a massive number of incoming transactions. Sure, they cheat a little, but it might teach us how to cheat in similar or different ways. For instance, they use "realms" to limit the number of players on a single server. Data engineers can also mimic that by the use of a good, pre-defined partition key. They also allow lossy transactions. Since you're going to be sending another transaction in the next milisecond, it's ok if we drop one. I don't know how to replicate that ability with data, but I'm willing to investigate the possibility.
Lastly, it was a great chance to meet up with old friends both from the Corporate world and from the Academic world. I was amazed at how many people I actually knew there.
Well, until next time...
Friday, December 16, 2005
Big Changes
I don't talk about my employer on this blog, but I did want to mention I'm changing employers. It is a very scary and exciting time for me. I have confidence that my new employer will be a great fit for me and will give me a number of challenges and plenty of opportunity for advancement. However, I will be sad to leave my current employer, the company has been good to me and I have a ton of friends I am leaving behind.
Saturday, December 10, 2005
Crossroads
Two companies, in different industries, stand at the crossroads. Both have chosen to make a continual investment in IT in order to beat their competitors. Both believe strongly in their long term plan. I think one will succeed and one will fail. However, until now I didn't know why I thought that; it was just intuition. I don't mind basing a decision on intuition, but I want to explore the decision afterwards to find out what the answer should have been.
In the case of the two companies it was in the IT strategies themselves. One IT strategy requires the continual purchase of depreciating stock. The other IT strategy requires the continual creation of appreciating assets. Both require heavy, year over year investments. The first model, due to depreciation, is actually an anti-strategy. Since your assets are always depreciating, it becomes easy for your competitors to catch up and eventually pass you. However, the second model eliminates the ability for your competitors to catch up because your assets are always appreciating.
Therefore, when contemplating the effect of an IT investment in your company, do your best to ensure that the outcome of the investment will be an appreciating asset instead of a depreciating one.
In the case of the two companies it was in the IT strategies themselves. One IT strategy requires the continual purchase of depreciating stock. The other IT strategy requires the continual creation of appreciating assets. Both require heavy, year over year investments. The first model, due to depreciation, is actually an anti-strategy. Since your assets are always depreciating, it becomes easy for your competitors to catch up and eventually pass you. However, the second model eliminates the ability for your competitors to catch up because your assets are always appreciating.
Therefore, when contemplating the effect of an IT investment in your company, do your best to ensure that the outcome of the investment will be an appreciating asset instead of a depreciating one.
Saturday, December 03, 2005
Comparing companies
I've recently been studying companies in an attempt to determine the best company to work for. One of the most interesting things that I discovered was that it varies depending on your risk/reward tolerance. To better represent these differences, I broke down companies into a number of different categories, or tiers. Companies across tiers cannot be compared because they have a different risk/reward structure that appeals to different people. Instead, only companies intra-tier can be compared to find a "best".
Tier A - These are start-ups. They are usually in someone's basement or spare room. They have a HUGE risk and can go boom or bust. Most often, they don't even last a year. They require long hours and the ability to live a few weeks without a paycheck.
Tier B - These are larger private companies. They either have not or do not want to go public. However, they are also more established so that the risk is not as large, but the reward is not as large either. They still require long hours, but can be very rewarding financially and socially.
Tier C - These are fairly new public companies; those that have gone public in the last 3 years or so. They still have the chance of doing great things, but much of the initial gain is gone. In addition, their beurocracy is starting to take shape and the system will disolve into process over the next few years. The risk is still there, as public companies can disolve or be bought out in their early, formative years. However, the risk is less than a Tier A and many Tier B companies.
Tier D - These are stable public companies. Usually these companies have a global name and produce hundreds of millions, if not billions, of dollars of revenue. The company is process laden and hierarchical. The ability to make money is diminished to a much smaller chance and the risk is very small as well compared to the other tiers.
Tier E - Government jobs. The reward is your salary and pension. The risk varies, but is often low. Typically, it is a process laden (burdensome) job and nothing more.
Each tier is attractive to different people. There is no point in comparing across tiers except to find the tier you want to work in. Once that is done, you should seek out companies in that tier and compare them. Are they market saturated? How is their health insurance? Is their stock going up or down? What is their pay rate? How many different things can you work on? What are the chances of movement, both with technology or people? Do they value the same things you value? Do you respect their leader?
All of these questions need to be answered in order to lead you to the right company for you, but don't get caught up in comparing cross tiers, for that way lies madness!
Tier A - These are start-ups. They are usually in someone's basement or spare room. They have a HUGE risk and can go boom or bust. Most often, they don't even last a year. They require long hours and the ability to live a few weeks without a paycheck.
Tier B - These are larger private companies. They either have not or do not want to go public. However, they are also more established so that the risk is not as large, but the reward is not as large either. They still require long hours, but can be very rewarding financially and socially.
Tier C - These are fairly new public companies; those that have gone public in the last 3 years or so. They still have the chance of doing great things, but much of the initial gain is gone. In addition, their beurocracy is starting to take shape and the system will disolve into process over the next few years. The risk is still there, as public companies can disolve or be bought out in their early, formative years. However, the risk is less than a Tier A and many Tier B companies.
Tier D - These are stable public companies. Usually these companies have a global name and produce hundreds of millions, if not billions, of dollars of revenue. The company is process laden and hierarchical. The ability to make money is diminished to a much smaller chance and the risk is very small as well compared to the other tiers.
Tier E - Government jobs. The reward is your salary and pension. The risk varies, but is often low. Typically, it is a process laden (burdensome) job and nothing more.
Each tier is attractive to different people. There is no point in comparing across tiers except to find the tier you want to work in. Once that is done, you should seek out companies in that tier and compare them. Are they market saturated? How is their health insurance? Is their stock going up or down? What is their pay rate? How many different things can you work on? What are the chances of movement, both with technology or people? Do they value the same things you value? Do you respect their leader?
All of these questions need to be answered in order to lead you to the right company for you, but don't get caught up in comparing cross tiers, for that way lies madness!
Thursday, November 24, 2005
Experiences
We are chained by our experiences. They bind us, control us, enslave us. They provide our definition of normality, by which we judge the world. We can obviously break from the bonds, but it is not easy. People who were abused as children have a higher chance of abusing their own children. Why? Because to them, abuse is normal. Notice that I didn't say right, but normal. I believe they still understand that it is wrong, and they still feel pain and remorse. However, it was what was done to them and therefore, they see it as normal behavior.
My father died when I was 20. To me, not having a father when you are an adult is normal. It seems weird to me when I hear my friends talking about thier parents. I don't have those experiences to draw on, so I have to extrapolate how it would have worked out, but it doesn't feel normal to me. Even as I look at my children's future, I often don't picture myself with them when they are grown; it wouldn't be normal.
How much do we judge people and situations based on our view of normality? How much could we prevent abuse by working to alter people's view of normality? How much do you try to extend your experiences to understand other people's view of normality?
For those who want to dispute my definition of normality, feel free. But, all things in life are tied to perceptions. What is normal is just another perception. In fact, what is right is just another perception - the only difference is who is doing the perceiving.
My father died when I was 20. To me, not having a father when you are an adult is normal. It seems weird to me when I hear my friends talking about thier parents. I don't have those experiences to draw on, so I have to extrapolate how it would have worked out, but it doesn't feel normal to me. Even as I look at my children's future, I often don't picture myself with them when they are grown; it wouldn't be normal.
How much do we judge people and situations based on our view of normality? How much could we prevent abuse by working to alter people's view of normality? How much do you try to extend your experiences to understand other people's view of normality?
For those who want to dispute my definition of normality, feel free. But, all things in life are tied to perceptions. What is normal is just another perception. In fact, what is right is just another perception - the only difference is who is doing the perceiving.
Tuesday, November 15, 2005
MIS Degree
Over on Code Craft, Kevin describes Three Theories on How to Use Developers Effectively. He describes theories by really smart techies, really smart business people, and the theory of interchangable parts. What does this have to do with MIS degrees you ask? Well, an MIS degree holds to the theory of interchangable parts. The person who seeks out the MIS degree doesn't have a specialty. He is not super technical, nor is he a business man. Instead, he spent one to two years studying different domains. While learning is always useful, I can't imagine how those two years wouldn't have been better spent learning the domain of the company for which you work, or learning the domain of the tools which you will use to solve those problems.
I must say that I understand the temptation. When I finished my bachelor's degree, I thought about getting a business degree because I wanted to help people solve their problems. However, I would have gotten an MBA because that would have given me enough details to understand the domain of the people whose problems I wish to solve. Paul Graham once said that a metaphore is a function applied to an argument of the wrong type. Specializing in technology, pursuing an MS or Ph.D. is designed to give you additional functions and additional types on which to build metaphores. Specializing in business, pursuing an MBA, is designed to do the same thing. Getting an MIS is an attempt to get you more comfortable with the functions and types you already know, which is not nearly as important to me.
If you're going to learn it, then specialize, you can always back up and be a generalist later, but your generalizations will be a lot more correct if you understand the specializations that determine them.
I must say that I understand the temptation. When I finished my bachelor's degree, I thought about getting a business degree because I wanted to help people solve their problems. However, I would have gotten an MBA because that would have given me enough details to understand the domain of the people whose problems I wish to solve. Paul Graham once said that a metaphore is a function applied to an argument of the wrong type. Specializing in technology, pursuing an MS or Ph.D. is designed to give you additional functions and additional types on which to build metaphores. Specializing in business, pursuing an MBA, is designed to do the same thing. Getting an MIS is an attempt to get you more comfortable with the functions and types you already know, which is not nearly as important to me.
If you're going to learn it, then specialize, you can always back up and be a generalist later, but your generalizations will be a lot more correct if you understand the specializations that determine them.
Tuesday, November 08, 2005
House pt 2
This week's house was great. I was just thinking today that they should show him more in a T-shirt and Jeans b/c that is what his personality type dictates he wear. Sure enough, that is what he was in tonight. I would love to meet the writer, he must be my twin. I think I'm going to start wearing a T-Shirt and Jeans to work and see how long I can get away with it. Even if someone complains, how long can I go without some kind of action...keep watching here for updates!
Tuesday, October 25, 2005
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!
"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.
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.
Thursday, October 13, 2005
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.
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...
Thursday, October 06, 2005
Double Entry Bookkeeping
Wednesday, October 05, 2005
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.
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.
Sunday, September 25, 2005
Paid Apprenticeships?
A minor rant. I hear now and again someone talking about the old craftsman ways and how an apprentice used to pay his master for services. Now, we expect our first job to pay us well and it is a terrible injustice. To that I can only say that we do pay for our apprenticeships, but it is now called college. Whether you agree or disagree that it is a valuable apprenticeship, it is one just the same and probably had the same value now as it did back in the olden days. So, the next time you think you ought to get paid for taking on an apprentice, go teach school.
Thursday, September 22, 2005
More on Company Death
I happen to like the beekeeper story, but I think it is incomplete. The author blames a company's demise on the leader leaving or changing, but I don't necessarily believe that is it. I think projects get larger and mature and they change in nature. Take Office. It doesn't have to get a ton of new whiz bang features out immediately. It has market share and it needs to maintain its dominance while not hurting quality. To do that, you add processes in place to control the change in the product and to ensure integration with other products. I'm curious if this is just natural product evolution. It doesn't have to be company wide. For instance, at MS the XBox, MSN Search, and V. Studio teams are still quite agile and seem to enjoy their jobs, where the larger, integrated systems people are miserable. Is it the leader? Is it integration? Is it complacency (wanting to maintain your product instead of revolutionize it)? Is it all 3? Why do some companies impose process in some areas and not in others whereas other companies impose process over the entire company at one time? What is the survival rate of each?
On complacency, I think that is a valid reason for a while. Office, in the past 5 years, has not had to revolutionize. I think that the open source movement and OpenOffice in particular has forced its hand and required Office 12 to be produced. However, therein lies the problem. When a new challenge faces a process laden product, it can't adapt. The top programmers have left to find projects with less process and processes have been inserted to maintain the quality in their absense. Now, the mediocre programmers are faced with a challenge that is too great for them, create a revolutionary project in Internet time. The processes don't allow it, the programmer's don't have the skills, and the result is a buggy product that is late and not close to what users expect or need.
Do I think MS is on its death throws? Most certainly not. It is too big to go down the tubes over night. However, many people thought the same thing about IBM and it lost huge amounts of market share and almost was divided into many separate, smaller companies. It took Lou Gerstner to turn the company around, eliminate the beurocracy, and get the company agile again. Coincidentally, Lou named his book, Who Says Elephants Can't Dance. It is a must read if you are in the technology sector as it directly addresses a company's shift from beurocracy to agility. Making a large company dance is an amazing feat. In Lou's opinion, it took a leadership change to make it happen. In fact, had he not come in time, they would have spun off many IBM divisions and it would have continued to decline. According to my interpretation of Lou, agility is not something that can come bottom up, it must be a leadership decision.
What about Oracle? How does it handle process? What are the other older and bigger tech companies: SAS, Apple, Sun - what do they do? What about larger tech companies that have failed: DEC, Compaq - what did they do wrong. I've studied Apple's problems and they seemed to stem from arrogance and a fundamental lack of marketplace economics, not process. It was more an unwillingness to change rather than an inability to change. Looks like it is time to hit the books...
On complacency, I think that is a valid reason for a while. Office, in the past 5 years, has not had to revolutionize. I think that the open source movement and OpenOffice in particular has forced its hand and required Office 12 to be produced. However, therein lies the problem. When a new challenge faces a process laden product, it can't adapt. The top programmers have left to find projects with less process and processes have been inserted to maintain the quality in their absense. Now, the mediocre programmers are faced with a challenge that is too great for them, create a revolutionary project in Internet time. The processes don't allow it, the programmer's don't have the skills, and the result is a buggy product that is late and not close to what users expect or need.
Do I think MS is on its death throws? Most certainly not. It is too big to go down the tubes over night. However, many people thought the same thing about IBM and it lost huge amounts of market share and almost was divided into many separate, smaller companies. It took Lou Gerstner to turn the company around, eliminate the beurocracy, and get the company agile again. Coincidentally, Lou named his book, Who Says Elephants Can't Dance. It is a must read if you are in the technology sector as it directly addresses a company's shift from beurocracy to agility. Making a large company dance is an amazing feat. In Lou's opinion, it took a leadership change to make it happen. In fact, had he not come in time, they would have spun off many IBM divisions and it would have continued to decline. According to my interpretation of Lou, agility is not something that can come bottom up, it must be a leadership decision.
What about Oracle? How does it handle process? What are the other older and bigger tech companies: SAS, Apple, Sun - what do they do? What about larger tech companies that have failed: DEC, Compaq - what did they do wrong. I've studied Apple's problems and they seemed to stem from arrogance and a fundamental lack of marketplace economics, not process. It was more an unwillingness to change rather than an inability to change. Looks like it is time to hit the books...
The Other Side
I really don't want to promote this guy's blog, but in the interest of fairness, I'll show the other side of the coin. This post describes why a business man believes Microsoft needs more process and more beurocracy, not less.
They just don't get it. There is a known connection between process and productivity, one that until recently I forgot. When labor unions want to strike, but cannot for whatever reason, they often strike "by the book." What this means is that they follow the process manual to the letter. Basically, no work gets done because all of the process gets in the way. It is a very effective tactic. The same holds true for companies, as process is added, productivity drops. The blog talks about the problems with bugs in the old MS software and how process should fix that. WRONG. You can't "process" the bugs out of the system. The delayed release of Vista, Monad, and Office 12 because of bugs shows that process doesn't help that. Instead, it drives away your best developers, causing MORE bugs, not fewer. It just goes to show that business people don't understand the relationship between quality craftsman and quality craftsmanship. They like to think in assembly lines and mass production. I hate to tell them, but the software industry isn't there yet, and may never be.
Of course, many companies don't need the best. They can settle for a prefabricated home instead of a custom built mansion. However, if you're life's work is hosting parties, then you better opt for the mansion and you better make sure it is built well. The same goes with software companies. If you're life's work is making great software, then you better hire and retain the best in the business.
They just don't get it. There is a known connection between process and productivity, one that until recently I forgot. When labor unions want to strike, but cannot for whatever reason, they often strike "by the book." What this means is that they follow the process manual to the letter. Basically, no work gets done because all of the process gets in the way. It is a very effective tactic. The same holds true for companies, as process is added, productivity drops. The blog talks about the problems with bugs in the old MS software and how process should fix that. WRONG. You can't "process" the bugs out of the system. The delayed release of Vista, Monad, and Office 12 because of bugs shows that process doesn't help that. Instead, it drives away your best developers, causing MORE bugs, not fewer. It just goes to show that business people don't understand the relationship between quality craftsman and quality craftsmanship. They like to think in assembly lines and mass production. I hate to tell them, but the software industry isn't there yet, and may never be.
Of course, many companies don't need the best. They can settle for a prefabricated home instead of a custom built mansion. However, if you're life's work is hosting parties, then you better opt for the mansion and you better make sure it is built well. The same goes with software companies. If you're life's work is making great software, then you better hire and retain the best in the business.
Subscribe to:
Posts (Atom)
