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.

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!

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.

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.

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!

Supreme Nerd

I am nerdier than 94% of all people. Are you nerdier? Click here to find out!

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!

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.

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.

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

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.

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.

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...

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.

Wednesday, September 21, 2005

The Perils of Integration

Thinking more about mini-microsoft and what has been posted by him and his readers, I wonder how much a company's downfall has to do with integration. When a company decides to integrate its systems into one mammoth system, it seems to spell doom. I think the process goes like this:

First, some senior executive decides that everything needs to be "integrated." This could mean that everything needs to work together, run on the same box, or in the same environment, who knows the exact definition?

This decision spawns a massive project and a few reorgs. The massive project introduces hundreds, if not thousands, of dependencies between teams. Managing these dependencies becomes too much for the teams and therefore process has to take over. The system is fragile and buggy, but any change to the system has to be approved by everyone else, and may cause everyone else to recompile or recode their part. Therefore, changes are to be avoided at all cost. It begins to take longer and longer to put out a release.

At this point, the individual teams have lost all power. The power is centralized into a few leadership individuals who make decisions, but don't know the technical details of those decisions and therefore can't understand the ramifications. It's not their fault, there are too many dependencies for ANYONE to understand all the ramifications. The teams can no longer respond to customer needs; they'd like to, but their hands are tied because if they change the Foo widget then it will cause a recompile of 5 other libraries and 2 months of testing - and the testers are already running on empty.

The best programmer's get frustrated. They can see the problem, but they can't put their finger on what exactly is wrong, plus they spend more time filling out forms and "communicating" then they do programming. They get disgruntled and leave for greener pastures. Those who remain are left maintaining systems that they didn't build and changes to the system are slower and more painful than before.

Finally, one of two things can happen, either the company can fold, or some spark occurs and the old, integrated system is left for dead and a project is started to build a new system that relies on customer teams and independence. The best programmers are hired to create the system and it becomes a success. Then the cycle repeats itself again.

Integrated systems are the hardest things to do correctly. As I've mentioned before it is our job to manage dependencies. The best way to manage a dependency is to eliminate it. With an integrated system, you have the potential to create an exponential number of dependencies, thus ensuring the demise of your company. Now, the question remains: how do you create an integrated system correctly? I'm not sure, but I'm going to think on it, so keep checking back here for the/an answer.

Mini-Microsoft and the Death of a Corporation

Mini-Microsoft is an anonymous Microsoft employee that is trying to change his company by airing its dirty laundry, publicly. I don't know that I agree with his approach, but I certainly feel sorry for him. It is sad to see a corporation leave the expansion phase and go into the recession phase, but all the signs are there. They have reduced or stopped raises, their earnings are slumping, they are using reorgs as a way to increase productivity, they are using process over people, and their best people are abandoning ship while those that stay have low productivity due to low morale. Microsoft had one of the longest expansion periods I've seen. Now, the giant has peaked and it must move into a recession phase. This is not to say that sometime, in the future, it can't expand again, but it must fall hard before that is to occur. Some of its products will decline as well, some have already been in decline. Some of its products may even excel: I'm a huge fan of C# and I think it will do well, though lack of true multi-platform support may hinder it (sorry Mono, you're not there yet). The warning signs are clear and its sad for the 50,000 people that work there. So long and thanks for all the phish.

C++ Tip: lower_bound and functors

Here's an interesting thing I learned recently via necessity. Let's assume you have a vector of string/int combinations.


vector<pair<string, int> > myvec;


Now, lets assume we add data to the vector, in sorted order (based on the string).


myvec.push_back( make_pair( string("A"), 0 ) );
myvec.push_back( make_pair( string("B"), 1 ) );
myvec.push_back( make_pair( string("C"), 2 ) );
myvec.push_back( make_pair( string("D"), 3 ) );


Finally, we want to search for a string key in the sorted vector using lower_bound.
We can't do the following:


lower_bound( myvec.begin(), myvec.end(),
string( "C" ) );


It will complain that there is not an operator<(std::pair<std::string,int>, std::string). Well, that is annoying, but we can write one. However, it is usually better to not clutter the global namespace with such functions and instead we choose to create a comparator function.


bool pair_str_less(const pair<
string,int>& lhs,
const string& rhs)
{
return lhs.first < rhs;
}


Now we pass in the comparator function

lower_bound( myvec.begin(), myvec.end(),
string("C"), pair_str_less );


Ouch! Now it complains that there is no pair_str_less( std::string, std::pair<std::string, int> ). It needs both permutations of function arguments! Unfortunately, we can only pass in one comparator! Perhaps it is not meant to be? Maybe we should just write our own version of lower bound? Or perhaps we should create a dummy std::pair from the string? Or, perhaps we can use functors!


struct pair_str_less
{
bool operator()( const pair<
string, int>& lhs,
const string& rhs ) const
{ /*...*/ }
bool operator()( const string& rhs,
const pair<
string, int >& rhs ) const
{ /*...*/ }
};


Now, we can use the pair_str_less function like


lower_bound( myvec.begin(), myvec.end(),
string("C"), pair_str_less() );

and the right version of operator() is chosen each way. Yeah!

Tuesday, September 20, 2005

Process vs Best Practice

I'm tired of process. Yes, I know it is supposed to help. Yes, I know it encourages responsibility and increases quality and decreases entropy and blah blah blah, but it is WRONG.

If you hire the smartest people, give them the best tools, and let them work, they will do the right thing, intrinsically. You only need process when your people have let you down. In fact, when you institute a mandated process, you are slapping your employees in the face. You are saying, "I don't trust you to get this right, so I, your leader, have mandated that you must follow these steps." The best people will follow the best practices. They will use version control, bug tracking, and change management because it is the right thing to do, not because someone forced them to do it. Moreover, they will also be able to choose when not to use it. The problem with process is that it must be blindly followed. It will bog your people and your company down in its forced standards. It will lower morale due to trust issues. It will lower morale due to developers being forced into the "one right way" (developers naturally resist standards and blind obedience).

Get the right people on the bus and get the process off the bus. Let the people find the best practices and let them have a great time producing great code.

Sunday, September 18, 2005

C# 3.0

There was a recent post on slashdot sending people to view a video of Anders talking about C# 3.0. For those who don't know, Anders Hejlsberg was the creator of Delphi and the Object Pascal language. Microsoft hired him away from Borland to oversee their .NET languages. While I think C++.NET is an abomination, C# is an amazing staticly typed language. It has stayed away from all of Java's problems and has adopted a much more agile flavor: very ruby-ish in nature. I've been reading the O'Reilly book on C# 2.0 and I've been impressed, but 3.0 looks like it will blow all other static typed languages out of the water. Kudos to Anders for giving us a language worth using. Now, I wonder about performance...

Another thing I found interesting about this video was Anders continual discussion of the "shape" of data. I've heard this term before (I think it was in Code Complete), but it had been a while. Acutally using C# to show the difference between rectangular data and heirarchical data was very interesting to me. It is something I'll have to start thinking about on a regular basis.

Dependencies

One of the most important jobs a programmer has is to manage dependencies. In fact, many of the Code Smells that we learn to avoid have their roots in the removal of unnecessary dependencies.

Especially evil are implicit dependencies (i.e., dependencies that are not easily noticed/not explicitly written). For example, once and only once is about the removal of implicit dependencies. Why? Because all instances of duplicated code depend on each other. If you have the following lines

int i = 0;
for( ; i < 10; ++i )
{
...
}
i--;

and you decide that the last i-- is a bug, then you have to remove the last i-- in every instance of the duplicated code - they are all dependent on one another. What's worse is that there is no semantic information associated with this code. It could be that one instance of the duplicated code actually precedes something slightly different so that the i-- is actually needed. Because there is no semantic information tieing all the pieces together, there is no way to know which i-- should stay and which should go.

Magic numbers, being another form of code duplication, have exactly the same problems; however, the problems with lack of semantic information is exacerbated with magic numbers. In the code above, there is no knowledge of what the number 10 represents. When you realize that it should be 15 do you change all the instances of 10 to 15? If not, how do you know which ones to change and which ones not to?

Dave Chelimsky discusses how to Manage Dependencies Not Aesthetics in his blog. He uses the following example:

display.print( person.getAddress().getZipCode() );

and then compares it with

display.print( person.getZipCode() );

and

person.printZipCode(display);

Which one has its dependencies managed correctly? Let's examine where the dependencies are. In example 1, there is a dependency from the main code to display, person, address, and zip code. There is also a dependency between display and zip code. Even though zip code is just a string, there is a logical dependency between the concept of a zip code and display.
In example 2, there is a dependency from the main code to display, person, and zip code. The dependency on address has been eliminated. There is still a logical dependency from display to zip code. In example 3, there is a dependency from the main code to both person and display, the dependency to zip code has been removed (even though the function still says zip code, the zip code is not seen or used in the main code, so there is no dependency). There is an additional dependency between a person and a display object.

Now, elimination of dependencies is not the goal, only the effective management of dependencies; however, it is much easier to manage a dependency that doesn't exist, just like it is much easier to maintain code that doesn't exist. I think we can quickly eliminate example 1 as being the best because it has no advantages over example 2 and an additional dependency. Example 2 does have an additional dependency over Example 3, but there are some trade-offs involved. With example 2, if the zip code changes, then the display class must also change. With example 3, if you want to write to something other than a display, then the person class must change. So, the question becomes which is more likely to change. Obviously this will change on a design by design basis.

Interestingly enough, the comments section of David's blog dives off into a discussion of formatters and visitors and how to isolate the change, but each introduces more dependencies in an effort to find the best dependency combination that is least likely to change. In this case, I might stick to the TDD principle of doing the simplest thing possible and then refactoring when we actually see the change, at that time you can make a more informed decision about what needs to be changed and how the change needs to occur.

Friday, September 16, 2005

J - A - C - K - E - TS

My daughter just cheered at her first game. Kindergartners through fifth graders had the chance to be "mini-cheerleaders" at tonight's football game. My daughter was very excited. She had her cheerleading outfit and her yellowjacket face tatoo. She knew the cheers and she was ready to go. I'll post some pictures of it over the next day or two. She did a great job for only being in Kindergarten. I was very proud of her, as always.

I certainly don't encourage cheerleading. I've known very few cheerleaders that I actually respected (two). I tend to think the "sport" is for the flighty, energetic people that I typically don't associate with because they have way too much energy and way too little intelligence for me. However, I made a commitment many years ago to support her in whatever she wanted to do (as long as it was legal and moral). I'll stand by that even if she wants to be a cheerleader, but I'm sure she won't -- she's way to smart for that ;0)

Tuesday, September 13, 2005

DRY needlessly

DRY, don't repeat yourself, has become a battle cry to many in the programming profession. Wiping out all causes of spatial, temporal, and logical repetition is the aspiration of today's elite. However, zealotry has never suited me, and I tend to think that there exists good repitition as well as bad. Let's look at some examples:

First, Test-Driven Development is full of repetition. The tests and the code define the specification separately, but equally. Yes, you can make up all sorts of excuses for why there is duplication, but the fact remains that both the tests and the code are asserting the same thing.
Second, in Code Complete, Steve McConnell talks about the practice of using a function to check another function's work. For instance, if you are making some difficult calculations, you may wish to write a slow and steady function that you know works and then write a swift and dangerous function that you are unsure of. In debug mode you would run both functions and ensure the identity of the results.
Third, web programming often has client and server side validation of input parameters. Yes, I know you could write a control file and have both generated from that, but I seriously doubt that is a big enough win to justify the programming time involved. The duplication is accepted as useful.

In each of these cases, we're using repitition to enable a sort of "double-entry bookkeeping". We perform our work and then check our work to make sure everything balances out. The duplication is there for a reason, to ensure quality and correctness. The duplication that DRY is intended to eliminate is not there to support itself, but is instead needless. Think of it as a teepee. You have two sticks leaning different directions, supporting one another. There is repetition, you have two sticks instead of one, but they are working together and leaning on one another. This is the key, if you have duplication in your code, make sure the duplication is leaning in opposite directions.

Monday, September 12, 2005

Forty Things Wiki

I've created a wiki where I can post my thoughts and preliminary drafts of Forty Things Every Programmer Should Know...But Doesn't! I'm using phpWiki because it was a breeze to set up and should be just fine for what I intend to do. Please feel free to contribute to The Forty Things Wiki, but be sure to leave your name so I can give you credit!

Sunday, September 11, 2005

Rake

Martin Fowler has a post on how to use Rake (a Make/Ant alternative written in Ruby). I'm going to give it a try sometime this week or next. I'll let you know how it works out.

40 Things Every Programmer Should Know

On my website I have started an outline of 40 Things Every Programmer Should Know...But Doesn't. There are eight categories consisting of 5 topics each. Obviously, most programmers will be familiar with some of the topics, and some will be familiar with many, but the hope is that there will be a few nuggets of interest lying in wait for the curious programmer willing to read my "book". The goal is not to have an in depth treatment of each topic, but a high level overview of what it is, when you would use it, and how and why it should make its way into your everyday programming life. I hope to complete one topic each week (or at least a rough draft). Keep checking in for progress reports.

Tuesday, September 06, 2005

Football pt ?

I have no idea what part I'm up to, but today I heard Dick Vermeil talk about Herm Edwards as someone who was an expert at his craft. For all the talk about software development being a craft, we now have talk of football also being a craft...the similarities continue.

Monday, September 05, 2005

Two Books

I read two books over the weekend, The Pragmatic Programmer by Andy Hunt and Dave Thomas and Programming Pearls by Jon Bently. Both were excellent books, though entirely different. The Pragmatic Programmer was about how to write robust systems and really began the craftsman movement. It discusses automated builds, regression tests, prototypes, estimation, source code control, text manipulation, code generation, and much more. It gives gems such as the correct answer when your boss asks how long it will take (the answer: "I'll get back to you."). It is about producing great software at all levels and is very similar in spirit to Steve McConnell's Code Complete, though it deals with design decisions much more.

Programming Pearls is about design in the small. It discusses how to choose the correct data structures and algorithms, how to determine complexity, and how to write efficient, fast code. If you didn't have a CS background, it would be an excellent book to give you a crash course. If you do have a CS background, it is an excellent in-depth view of small design decisions and is a timeless classic.

I definitely recommend both books and give them ***** out of *****!

Automated Build

Since I couldn't do much physically this weekend, I decided to practice what I preach and create an automated build for one of my projects. First, I'm embarrased that I hadn't done it sooner. Automated builds are one of the top three things that make a project successful. It is rather pathetic of me that I hadn't yet done it. However, I took the time this weekend and did a decent job of it. I hope that next time I can get it done early in the project instead of procrastinating like I have. In all fairness to myself, I have been working on some necessary infrastructure components so that the automated build can be easy to create and maintain, but I still should have got it done sooner. Anyway, it is done now and I can breathe easy!

Saturday, September 03, 2005

Scooby dooby doo...

Where are you?

Well, I haven't been able to post too much as of late because I've had gall bladder surgery. It really isn't that bad anymore, it is an outpatient operation. They do it laproscopically, so you only have a few small incisions. I'm a little sore, but not too terribly. Hopefully, I will be back to blogging regularly again in the next day or two, at least by Monday. See you then!

Sunday, August 28, 2005

PI and New Voyages

My phone number, minus the area code, begins at the 19,549,226 digit of PI. Find out the location of your special number.

Also, some Star Trek TOS fanatics have begun production of Star Trek: New Voyages. This is a fan fiction series of shows similar in spirit to the original television series. Like the original series, the acting is atrocious. Unlike the original series, the writing is atrocious as well. However, there is an upcoming episode written by DC Fontana, so we'll see if she fixes things up.

Code Kata

I've been investing some time in Code Kata. They seem to be an intruiging way to learn a new language and hone your skills. To that end, I am collecting a list of the most useful programming kata. Here are the ones I have so far:

Binary Search
Data Munging
Bloom Filters
Anagrams
Objectives
Checkout
Sorting
Code Comments
Trigrams
Dependencies
Word Chains
The Bowling Game
Prime Factors
Calculate the digits of PI
Eight Queens problem (N-Queens Problem)
Secret Santas
Sokoban
Countdown
Banned Words
Scrabble Stems
LCD Numbers
Animal Quiz
Paper, Rock, Scissors
1-800-THE-QUIZ
Roman Numerals
Texas Hold 'em
English Numerals
Knight's Travails
Barrel of Monkeys
Cows and Bulls (Mastermind)
Sodoku Solver
Center Strings
Format Number List
Survey Says
Four Letter Words
Histograms
Hangman
A Balancing Act
Interesting Anagrams
Repeated Substring

Virtual Reality Drawings

Very impressive, worth a moment of your time.

Virtual Reality Drawings

Friday, August 26, 2005

Site Update

On the right hand side of this page, I added links to RSS feeds that I monitor. Some are friends sites, but most are blogs with interesting opinions and insights into software development. I encourage you to check them all out!

Thursday, August 25, 2005

Pragmatists and Academics

I am an oddity, I consider myself a pragmatic academic. In the world of software development, that is a rarity. Most software developers are pragmatists. They attack a problem as soon as they encounter it. They surf web pages to find code to cut and paste, then they hack away at the code until it appears to do the right thing. They never understand the code, they only look at its results. A problem, to a pragmatist, needs a solution. The solution is correct if it produces the desired results. The wheel is recreated over and over again because time is not invested in understanding the problem and other attempts that have been made to solve it. The other side of the spectrum is the academic. The academic doesn't really care for real life problems. They abhor messy details and like to live in a fantasy land of imaginary computers and perfectly formed input. An academic loves to analyze a "real-world" problem, but only to abstract out the most interesting part and solve it in a vacuum, often rendering the solution useless for the general case. Neither is a panacea, but both are valuable when used correctly.

I feel I offer a unique value to a company because I'm a hybrid. I begin by attempting to understand the problem. I want to create the academic model. I want to look at each part of the problem in an abstract manner. I want to create precise nomenclature and definitions. I want to avoid the nasty details and solve the problem in a pristine environment first. However, I'm also a pragmatist. I realize that the real world needs real solutions. I realize that good solutions require dealing with unseemly details, but I also realize that coding a good solution is more than hacking some internet code until it appears to work. As I've discussed before, software development is a craft, and we must take our craft seriously or no one else will. By understanding the craft and attempting to provide deeper insight into problems, I hope that I am showing that the craft can be done right, and helping to pave a road that will make other's travel less difficult.

A Tale of Two Recruiters

Last week I had two recruiters contact me, let's call them Jack and Jill. They were both very nice and professional. When I let them know I wasn't on the market right now, they each had a very different response. Jack responded like I wish telemarketer's would. He left me alone. Jill responded like I think recruiters should, she asked for more information so that she could perhaps help me in the future. I like to make contacts and network, so I graciously answered Jill's questions, but more than that, I felt like Jill was honestly interested in helping me, not just herself. Guess who I'll go to first if I ever need a job? That's right, Jill. By showing interest, she has gathered my support for a longer term relationship. I think that is true for any endeavor, listen, ask questions, take notes. You never know when you might need a bridge built.

Monday, August 22, 2005

BugBash

BugBash is a great comic strip about life in the trenches, especially for testers. Check it out!

Sunday, August 21, 2005

New blogs

I have decided to separate out my content into multiple blogs. Therefore I have created Thoughts of KC to hold my football related blogs, and Thoughts of He to hold my religious and personal ramblings. This blog will continue to hold software development and miscelaneous topics. See you there!

NFL Preseason Week 2

Ok, after this weekend's games, here are my updated predictions. After the 3rd preseason game, I'll give win/loss record as well.

AFC East: New England, NY Jets, Buffalo, Miami
AFC North: Pittsburg, Cincinatti, Baltimore, Cleveland
AFC South: Jacksonville, Indianapolis, Houston, Tennessee
AFC West: *Will be updated after San Diego Game*

NFC East: Philadelphia, NY Giants, Dallas, Washington
NFC North: Minnesota, Detroit, Green Bay, Chicago
NFC South: Atlanta, Carolina, New Orleans, Tampa Bay
NFC West: *Will be updated after St Louis Game*

Windows HX

I was going to do this blog in podcast format for Gretchen's contest, but I couldn't find a microphone. So, I thought I'd just post it on my blog :-)

In this blog, I'd like to discuss a long term strategy for Windows that would help it to overtake Linux in the IT sector.

I believe that Linux's newfound popularity in the IT workplace stems from a couple of factors. In this brief, we're going to explore one that I think is easily solvable. I believe that great hackers begin cutting their teeth on linux. It is a free system that gives them quite a bit of flexibility and power. Most hackers don't have a lot of money to buy development tools and operating systems, so having a large amount of free software to choose from really gives them a head start. Obviously, hackers don't make IT purchasing decisions, so why should this affect Window's strategy? Because hackers grow, they join companies, they start making recommendations, and their ideas and background eventually affects the direction of IT. Furthermore, companies that want to attract great hackers have to use the tools that great hackers want to use.

Secondly, Universities can use and explore Linux's source code. This gives students a familiarity with Linux so that companies that are looking to hire IT workers can find more college graduates that are experienced in Linux programming than windows. This can affect an IT department's decision to go to Windows or Linux; obviously if they can find more cheap Linux talent than Windows then they will lean that direction.

Finally, being open source, many hackers feel like they might be able to contribute Linux and that gives them a sense of importance. Having a commit to Mozilla or perl or having a java program on source forge is a buzz to most programmers. Linux, is like the Mecca of open source projects, so naturally programmers will flock to it like moths to the flame.

I think Microsoft can address these deficiencies with a small investment; something I would call Windows HX (Windows for Hackers). Windows HX would be an open source version of Windows. It wouldn't need to have all the features of Windows XP; it would be targeted for the Hacker population. It would need to have great command line support (think Monad) and excellent developer tools would put it far above Linux. It would also need to come with free "web server" tools (whether or not you want to give away a scaled down version of Microsoft's or use Apache isn't that important). Windows HX should be run as an open source project. I would not base it on the current Window's source code, but instead I would get a small core of functionality working, then release it into the open source community with a Microsoft Employee as the "pumpking". This would allow Universities to have an alternative to Linux when studying operating systems, it would also give open source programmers something to strive for in the MS arena. Moreover, it would...Oh, my blog space is filling up ;-) If you'd like to hear the rest, you'll just have to give me a call.

Saturday, August 20, 2005

School Year

The school year is starting up. In addition to my day job, I also teach at nights at a local community college. Some people ask why I teach such a low level class, but I really get a lot from it. I teach a night class, which means that I end up with older people who have never used a computer before or are only just starting out. It is very rewarding to help them to understand what a computer does and how to use various programs (internet, email, word, excel, and powerpoint). It certainly isn't solving world hunger, but I know that in some way I'm making a person's life better, and that is good enough for me.

This school year is also exciting for a few other reasons. First, this is my daughter's Kindergarten year. She is so excited to be going into public school. Her teacher and I went to school together, so it should be a good year for my daughter. Besides, she's a smart girl. I honestly thought about letting her skip Kindergarten b/c she already knows everything they're going to teach her, but I figured there was some maturity that needed to be gained first.

The other reason that this school year is exciting is because it is my wife's last year. In May, she will have graduated with a degree in Nursing and become an RN. I'm very proud of her, going to school and being a mother to two children is very difficult. Moreover, at that point, we will no longer be tied to our current hometown or even our current state. We can choose to move wherever we want. I'm a person that loves possibilities, so May will be a very exciting time as I explore all the possibilities available to me and my family. I'm working hard right now to increase my network of recruters and IT industry people so that I'll have lots of choices when the big day comes. Stay tuned to see what happens!

Friday, August 19, 2005

Freedom

I was over at a friend's house a few days ago and the topic of conversation switched over to politics. He felt that we should give up some of our freedoms in order to be safe. I couldn't disagree more. Our country was founded by people risking their life to obtain freedoms they didn't have in their home country. I don't want some cowardly terrorist to mar their bravery. I would gladly give my life if it meant that my country could remain free. Unfortunately, with the PATRIOT Act and other recent legistlation, our country is headed down a path whose results I fear. In the immortal works of General Stark Live Free or Die!.

Thursday, August 18, 2005

Growth

There are three phases of a product or companies growth and the passage from one phase to another is a critical time. The first phase is the niche market phase. The company or product is small and addressing a niche market, with a small number of customers. The second phase is the "kool-aid point". At this phase, the company or product is gaining clients that have passion, clients that have "drank the kool-aid." The final phase is when the company or product moves to powerhouse status, a global Fortune 500 level company. There are very few individuals who can start a small business and run it as a global company. most of the time, a new leader must emerge at each phase, the old leader is kept for historical reasons, but the new leader is responsible for managing the transition and leading the company into the new era. It is arrogant for us to think we can handle all three phases. People, by their nature, are specialists. It is ok to fail at something. It is also natural to excel at other things. Sometimes we have to put our pride behind us for the good of others.

Sunday, August 14, 2005

Preseason Picks

Based on the first full week of the preseason, here are my 2005-2006 picks. Note that this WILL change as the preseason progresses.

Try it yourself, then scroll down to see the solution.




















AFC EastAFC NorthAFC SouthAFC West
New EnglandPittsburghJacksonvilleOakland
N.Y. JetsBaltimoreIndianapolisSan Diego
BuffaloCincinnatiHoustonKansas City
MiamiClevelandTennesseeDenver







NFC EastNFC NorthNFC SouthNFC West
PhiladelphiaMinnesotaAtlantaSeattle
N.Y. GiantsDetroitCarolinaArizona
DallasGreen BayTampa BaySt. Louis
WashingtonChicagoNew OrleansSan Francisco

Saturday, August 13, 2005

Generic vs Generative Programming

There is a difference in Generic and Generative programming, though C++ doesn't see it. Generic programming is about not having to specify the exact type when you are defining a class or function. This is a staple of the C++ STL. A vector can be a vector of ints, floats, strings, or foos: it doesn't matter. Generative programming is the ability to create code at compile time. For example, loop unrolling, fixing a buffer size, and choosing the correct version of a function to call at compile time is an example of generative programming.

C++ supports both Generic and Generative programming through the same language mechanism, templates. That sinking feeling should have come over you already. Using the same language feature for two distinct operations is never a good idea. Java does not support Generative programming, though Java 5.0 has recently introduced template support for Generic programming. One interesting language to study in this regard is Template Haskell. Template Haskell uses Haskell's module system to support Generic programming, but adds a new syntax to support Generative programming. I hope that other languages start supporting two unique syntaxes for these unique programming styles as well.

Thursday, August 11, 2005

Casual Fridays

You must read this blog. I can say no more about it.

Wednesday, August 10, 2005

Name that Tune!

Do you like pop music? Want to try your hand at guessing artists and titles based on lyrics? Then try Song Lyrics of the Day and Today's Lyric.

Good luck!

Sunday, August 07, 2005

Heron

There's an interesting programming language developed by Christopher Diggins known as Heron. It is a language similar in spirit to C++ but with some modern software engineering techniques such as contracts built in. More interestingly, he is playing with concepts. Conceptual programming will, if done right, be the successor to Generic Programming (i.e., programming with templates). Conceptual programming allows structural conformance rather than name conformance. It is similar to duck typing (the definition on Wikipedia is essentially correct, though the history is screwed up). Another interesting language is Scala. I'm just beginning to look at it, but it looks to be a rather modern alternative to Common Lisp and CLOS. I'll keep you posted.

Saturday, August 06, 2005

The Alcohol Test


Bacardi 151
Congratulations! You're 134 proof, with specific scores in beer (40) , wine (100), and liquor (121).
All right. No more messing around. Your knowledge of alcohol is so high that you have drinking and getting plastered down to a science. Sure, you could get wasted drinking beer, but who needs all those trips to the bathroom? You head straight for the bar and pick up that which is most efficient.





Link: The Alcohol Knowledge Test written by hoppersplit on Ok Cupid

Green Bay vs Buffalo

Last night I watched the scrimage on the NFL network between Green Bay and Buffalo. Now, this is each teams first scrimage this year, so I didn't expect a lot, but I'll give a few comments on what I saw. As a disclaimer, I have to say that I'm a Chiefs fan and don't care about the Packers or the Bills.

My thoughts on the Packers

  1. Green Bay Defense was never in the right place. For the most part they wrapped up well, and I was happy to see that. However, they had to wrap up a lot because the receivers were typically wide open. Furthermore, they let Buffalo's runners run all over them.

  2. Brett Favre telegraphed every one of his throws. I'm seriously surprised that he didn't have about 10 throws picked off. It was a testament to his skill that he could stare down the receiver for the one second his offensive line gave him and still get the ball to him.

  3. Javon Walker shouldn't have held out, period. At this scrimage the GB Packers management looked smart for not giving in as Javon looked like a first year player.

  4. I hope the Packers' offensive line becomes less offensive and more defensive of Brett. The quarterbacks had absolutely no time to throw and were constantly being hasseled. At the end of this season, Brett is going to wish he had retired.

  5. The Packers better hope that Bubba Franks come back because they have no depth at tight end. In fact, they better hope that no defensive player gets hurt because they have no depth there, either



My thoughts on the Bills

  1. JP Lossman didn't do poorly, but I can't say he did exceptionally well, either. Toward the start of the scrimage he did his best, it seems the defense caught on to him pretty quickly though.

  2. Willis McGahee showed why they no longer have Travis Henry, he was amazing. He was tearing up huge tracks of land in no time. The Bills just have to hope he doesn't go down.

  3. The Bills defense was good, but it is hard to tell in a scrimage exactly what is going to happen in a real preseason or season game. They wrapped up well and didn't give Ahman Green room to run; however, it could be that the Packers offensive line was so bad that they didn't have to try very hard.

  4. Kelly Holcomb looked great against the second team defense of Green Bay. Then again, I might look great against the second team defense of Green Bay. I'll be interested to see how he looks during the preseason.



Of course, this was just a scrimage and things will change the more the preseason continues. I'll continue to monitor these and other teams and give you my opinion. Your milage may vary.

Tuesday, August 02, 2005

Hell's Kitchen

Tonight was the final episode of Hell's Kitchen. If you haven't seen it, it is a reality show where Master Chef Gordon Ramsay has 12 aspiring chefs attempting to win their own restraunt. I really respect Gordon. I would love to train alongside that man. He has a passion for what he does, he is creative, he is confident, and he is a perfectionist. He has all the traits of an excellent Master Craftsman. Tonight, the two survivors squared off to see who would get their own restraunt. On one hand was the polished salesman, Ralph. Ralph is a freelance chef from New Jersey. He dresses appropriately, has the "right" attitude, and is dependable. On the other hand is the creative guy, Micheal. Michael is an executive chef from Colorado. He has a body full of tatoos and is shy and a bit schizophrenic.

Each contestant gets to create his own restraunt and menu. Ralph chooses a throwback to the 20s. He creates the traditional Italian Steakhouse. It looked like a very elegant New York restraunt, which is exactly what he wanted. Michael decided to go contemporary. He created an LA "mod" restraunt with a flareful, imaginative menu and a private, but relaxed dining experience. Ralph's waiters were a focus point, dressed in bright red shirts with black pants, while Michael's were afterthoughts in grey and black attire.

Each Chef had to manage a hot plate. Michael struggled with this, while Ralph performed well. Michael had a hard time gaining respect with his mild mannered demeanor; whereas Ralph's bubbly personality kept everyone moving. However, Ralph chose personnel poorly and had to spend much of his time away from the hot plate and in the kitchen, covering for others mistakes. Michael's personnel was much better and he could focus his attention on quality control.

In the end, both had excellent nights. Both restraunts were given rave reviews by the diners, and they had 90-94% of their customers say they would return, a truly phenomenal number. So, which one did Gordon pick?

He chose Michael. In particular, Gordon commented on Michael's creativity. This bolsters what I said earlier. Software development, like cooking, relies heavily on people and thier creativity. We all have the same basic ingredients (if,while,for,data structures,algorithms) and the same recipies(design patterns, idioms) but it is how we piece them together that gives us a great Beef Wellington or an overcooked Steak Tartar. It is that intuition and creative ability that separates the truly great chefs of the world from the average Joes. I respected Gordon before, but after that choice, when I saw that he got it, I admired him. He looked past Michael's form and saw his true function.

Afterwards, Gordon even offered Michael a chance to move to London and work in one of his restraunts alongside him. Michael, like a good Journeyman, accepted. I would have expected no less from Michael; he gets it too. I wish all of our executives were like Gordon, masters at what they do, demanding perfection from others, giving perfection in return. I just hope they do a sequel :-)

Monday, August 01, 2005

Architecture

Most of the experts are beginning to converge on the idea of software as Architecture. At one time it was mathematics, then engineering, now architecture. I am fond of this idea. The goal of architecture, like that of software, is to make a product that suits a given purpose within given constraints (building codes, cost, etc...). There is also some artistic aspects of both: desiging a user interface is similar to designing a house (which is essentially a user interface). For the same amount of money and functionality you can get completely different structures, some usable, some not. In addition, you can use cheap labor to build the house or more expensive labor. If you opt for the cheaper labor, then you are likely to have quality problems down the road.

Architecture is essentially about the creative genius of a person. A Frank Lloyd Wright original is infinitely better than a prefabricated construct, though both may be made with the same material. It is the creativity and imagination of the builder that makes the product amazing. Also like architecture, creation is more about patterns than components. Often, there doesn't exist a component to do what you want; therefore, you have to build it using patterns and principles to create the best component possible.

There are a lot of similarities between architecture and software development, more so than engineering or mathematics. Now we just have to look for similarities between architects and computer programmers.

Sunday, July 31, 2005

Creativity

Unfortunately, in the world of business, businessmen don't understand software developers. Numbers, theories, and mind games don't interest them. Too often, businessmen are salesmen by nature. They need everyone to look sharp and say "Yes" when appropriate. Businessmen get disgruntled when programmers don't act the right way or dress appropriately. They don't understand the creativity required to program: creativity that has to express itself in other ways, such as appearance. Instead, they feel these people are just hoodlums; necessary vermin that should be locked away or forced to conform.

Truly great programmers are non-conformist by nature. They will break the mold subtley but significantly. In my opinion, you should cultivate that. In fact, successful technology companies do. Microsoft, Google, and Apple all cultivate creativity. IBM, for many years, did not. They eventually became a services company because their mindset was too dogmatic to allow creative geniuses to flourish.

How many of the following pioneers of computer science fit your company's dress code? Most of them are not freakish by nature, but each displays a creative flare, a hint of being anit-establishment.

Linus Torvalds
Bjarne Stroustrup
Dennis Ritchie and Ken Thompson
James Gosling
John McCarthy
Steve Wozniak
Leslie Lamport

Saturday, July 30, 2005

Football pt 5

The next similarity between football and software development is that a great team player will always plan to have a successor. In any given season, a player may blow out a knee or separate a shoulder or have any number of other injuries. A backup will have to come in and perform just as well. A great team player will make sure that the incoming player will know everything he needs to know in order to play his best. A software development team is similar. People get pulled off projects, leave companies, teams, etc... At any given time, a programmer should make sure that his successor knows everything his mentor knows. This includes both project and non-project related knowledge. You can be a truly great player without doing this, but you'll never be a truly great team player.

Monday, July 25, 2005

Avoidant

I thought I would start examining some of the personality disorders listed in my previous blog and tell how they apply to me. The first is Avoidant.

Here is a description of Avoidant.


  • avoids occupational activities that involve significant interpersonal contact, because of fears of criticism, disapproval, or rejection

  • is unwilling to get involved with people unless certain of being liked

  • shows restraint within intimate relationships because of the fear of being shamed or ridiculed

  • is preoccupied with being criticized or rejected in social situations

  • is inhibited in new interpersonal situations because of feelings of inadequacy

  • views self as socially inept, personally unappealing, or inferior to others

  • is unusually reluctant to take personal risks or to engage in any new activities because they may prove embarrassing



For starters, my occupation, computer programmer, allows me to avoid almost all significant interpersonal contact. Working from home increases that avoidance.

I've gotten better at bullet #2. In high school, I wouldn't even talk to someone unless they talked to me first. I still have a hard time establishing confidence in many scenarios, but it has gotten better.

#3 probably gets me in the most trouble. I think my restraint goes far beyond intimate relationships and into day-to-day relationships as well. I try to ensure that as few people as possible know anything about me (well, this blog breaks that mold, so that's probably a good thing). Even little things like what I want in a career are kept to myself, which makes it very hard for employers to make me happy; they have to guess what I would want, which is, most probably, what I don't want.

#4 just means that I don't talk in social activities because I'm afraid to say something stupid, which is true.

#5 is definitely on the mark. I usually feel that I don't measure up to most people - that I couldn't do as well a job as them or that I would never be able to fill their shoes. This keeps me from pushing too hard for a promotion because I feel I wouldn't do as well as the person there now.

#6 is actually true, I am socially inept, personally unappealing, and inferior to (most) others. If I did not have those characteristics, but I thought I did, then this would apply. However, since those characteristics already apply to me, then I'm justified in feeling that way. So this one doesn't apply.

#7 This one rings true as well. One of the reasons I didn't take a recent job offer is because the people there were much smarter than I and therefore I would look stupid in comparison to them. I don't have to be the smartest, but somewhere in the middle would be nice.

So, I think Avoidant suits me nicely. It doesn't really bother me, I can't say that I'm overly unhappy, so I'll probably remain Avoidant - at least for the time being.

Sunday, July 24, 2005

Here's the results from my Personality Disorder Test. Turns out I might be heading for schizophrenia after all :-(

DisorderRating
Paranoid:Moderate
Schizoid:High
Schizotypal:High
Antisocial:Moderate
Borderline:Low
Histrionic:Low
Narcissistic:Moderate
Avoidant:High
Dependent:Low
Obsessive-Compulsive:Moderate

-- Personality Disorder Test --
-- Personality Disorder Information --

Disney World Eating Establishments

This will be the first of many blogs discussing Disney World. In this blog, I've chosen to discuss the very best and very worst restaurants in the World. I'll divide them up by Theme Park (Magic Kingdom, EPCOT, MGM Studios, Animal Kingdom). You'll notice that most of these restaurants serve very starchy, high carb foods. This is on purpose. They say you walk an average of 10 miles a day while you're at Disney World, so you'll need the energy.

Magic Kingdom - There's not very many restaurants that are worth eating in the Kingdom.
Crystal Palace - This one you shouldn't miss. I really enjoy the character lunch with Winnie the Pooh, but they also serve breakfast with Winnie. For breakfast, they have a traditional buffet with eggs, bacon, sausage, etc... For lunch they have a number of pastas, vegetables, and other buffet dishes. If you go, be sure to try their pink lemonade.
Cinderella's Royal Table - I really can't recommend the food here. The breakfast is plain and uninspired, but it is a character breakfast with the princesses. Typically, you have to make reservations 120 days in advance. If you're interested in a princess breakfast, you may have better luck with Akershus. To get a reservation here for breakfast, you must call within the first 15 minutes of the reservationist opening (1-800-WDW-DINE) 120 days before your expected dining date.
Pecos Bill Cafe - If you are looking for something quick, then this is probably the place for you. Pecos Bill Cafe has the best hot dogs in the Kingdom and the best condiment bar to go with them. Definitely not elegant fare, but good for a quick bite.
Liberty Tree Tavern - This restaurant serves its food family style. You get a selection of ham, roast beef, and turkey along with side items such as mashed potatoes and gravy, stuffing, and green beans. You also get, for dessert, apple crisp with ice cream. The food is served on large plates and bowls and you get to scoop out your serving. It is also a character dining at supper with Mickey, Minnie, and an assortment of other friends.
Tony's Town Square - Italian food right inside the gates of the Magic Kingdom. It's not exceptionally good, nor is it exceptionally bad. My son really liked the calamari, but I'd avoid it for one of the other restaurants listed here. However, if you're trying to get a dinner reservation at the last minute, this usually makes a good choice.


EPCOT has the best restaurants in the World. If you go during October, be sure to try out the food and wine festival. It is a celebration of foods and wines from across the Earth.

Nine Dragons - I love Chinese food and this is some of the best I've ever eaten. I especially recommend it for lunch. They have a sampler/combo lunch that allows you to try many of their excellent dishes. It is definitely a must try.
Restaurant Marrakesh - This is a Morrocan restaurant and the food is magnificent. Furthermore, you are entertained with a collection of Morrocan music and belly-dancing. What more could you ask for?
Tangierine Cafe - This is a counter service restaurant near Marrakesh that serves Grecian fare. The food is very good when you're looking for something quick to snack on.
Akershus - Once again, a Princess breakfast with the same plain and uninspiring fare. However, if you have a little girl, these are must dos!
San Angel Inn - A lot of people highly recommend this restaurant, but I've never had good food or service here. It might be worth a try, but I recommend the other restaurants much more.

MGM Studios - The food here is respectable, but not amazing. There are a number of sit down eateries that are interestingly themed and therefore worth the time.

Sci-Fi Dine In Theatre - I've never actually eaten here, but it looks like a lot of fun. You sit in cars and watch a "B" movie on a big screen.
Mama Melrose's Ristorante Italiano - Not much on atmosphere, but the food here is really good.
50s Prime Time Cafe - This is a fun place to dine. You sit at a table and watch 50s reruns while you eat, and if you don't clean your plate then you're going to get made fun of! All in all, a fun place to eat and the food's not too bad either!
Hollywood and Vine - This is a buffet style restaurant that doesn't have much in the way of atmosphere, but the food is good and you can get in and out quickly.

Animal Kingdom - Animal Kingdom closes early, so you won't eat supper here often. For lunch, the best thing to do is find something quick and cheap because there doesn't exist a decent restaurant in this park. If you are interested in a character breakfast you can try Restaurantasaurus to eat with Donald and the gang.

There are also a number of great restaurants in the hotels of Walt Disney World.

Grand Floridian Resort and Spa - This has three of the best restaurants in the World.

1900 Park Fare - This is a character dining experience with an excellent buffet. I really enjoy eating breakfast here with Alice in Wonderland and Mary Poppins. Also, if you go, be sure to order a Mary Poppins to drink. It is fresh strawberry and orange juice and it is delicious!
Grand Floridian Cafe - If you're in the mood for soups and sandwiches, the Grand Floridian Cafe is the place to be. They have some exotic variations on the norm and it is all quite excellent.

Contemporary Resort - This resort contains Chef Mickey's, a delightful place to eat breakfast. The breakfast is buffet style and Mickey and his friends come around to your table to ensure you're having a great time.

Polynesian Resort - If you have time, you should definitely experience the Spirit of Aloha show. It is a luau dining experience that includes excellent food and an incredible show. I think my daughter was 2 when we went and she loved it. She even got to dance with the luau girls.

Animal Kingdom Lodge - The AKL features two great restaurants, Boma and Jiko. Boma is a buffet featuring fare from Africa. The food there is amazing, even for breakfast. Jiko is a more elegant dining experience, but has some of the best food in the World. If you're interested in a quieter atmosphere and higher priced food, this is the place to go.

If I've left something off the list, it is probably because I haven't visited there. If you're interested, just leave me a comment and I'll try it the next time I go.

Friday, July 22, 2005

Football pt 4

In football, you couldn't survive without a strong head coach. It is the head coach that ensures everyone is going in the same direction. It is the head coach that enforces 2 a days and creates schemes and studies the opposition. They make sure that the team only has to worry about studying hard and performing thier best. In software development, this is the Architect. It is his or her job to analyze the problem and get everybody attacking the right solution. It is his or her job to work through the team leads and make sure proper mentoring and "coaching" are being done. A team of head coaches couldn't run a football team properly anymore than an architecture team can create a product correctly. For good or bad, there must be a single person responsible in order to ensure a singular vision and consistency in the product.

Thursday, July 21, 2005

Schizo

When I was in Junior High (I'm not sure of the grade, maybe 6th or 7th), I created a world. This world was one of my own choosing. I used to lie in bed and pretend I was in this world and I would "live" there until I went to sleep. It was my way of coping with the problems in my life: I would escape to my world and be happy. My world changed as I grew older and met new people and did new things, but I always went back there every night. In fact, I started spending more and more time there. During high school, I was asleep or in my made up world almost as much as I was in the real world. Looking back, I wonder if that is how schizophrenia develops? Perhaps it starts as a harmless escape that eventually consumes the escapee? For me, it became too depressing to leave my world, so I just stopped going. I assume if I went back it would be covered in cobwebs; but what if someone made a different choice? What if it became too depressing to leave their world, so they didn't leave? Does anyone else have experience with this? I'd love to hear your stories.

Football pt 3

As in football, a team is made up of individuals who must learn to work together. The reason why a football team can't be put together in one year is because they have to learn to "gel". They have to understand one another's upsides and downsides so they can play to one another's strengths. In addition, a team of all star players probably won't outperform a team of good players with the occasional all star. Too many all stars will get in one another's way (too many chefs spoil the broth). Therefore, a team must contain the right mix of personalities and talents. That's not to say you shouldn't hire exceptional people, just that the personalities should be taken into effect when creating a team. A team of prima donna's will never work. A couple of examples from the football world. First, the Kansas City Chiefs defense last year. Year before last the Chiefs defense was abysmal. The players were getting beat badly. They decided to keep all the players and only change the coach. This didn't work. You have to have great players in order to play great. Second, the Oakland Raiders defense last year. They brought in a number of really good seasoned veterans, but the defense never gelled. They had great players, individually, but as a collective whole, they could not perform. Third, the Indianapolis Colts offense. They have great players individually that are selfless and perform well together. They are one of the most dominant offenses in the league. Finally, the New England Patriots defense. They have a core group of great players and many other players that "fit the system." These players are not exceptional, but they understand their role and they play it well. The New England Defense was rated very highly last season and it was the reason they went to and won the Super Bowl.

Monday, July 18, 2005

Controlling Factors

As I think more about control I realize that the three root issues (Pride, Greed, and Lust) are just ways of grasping control from God. There is only one sin, disobedience of God which manifests itself in the form of you controlling your life instead of allowing God to control it. However, the ways it manifests itself are in the forms of Pride, Lust, and Greed. Of course, all three may surface for any individual, but usually one is more prevalent than others.

A prideful person is intent on controlling the past - either by reliving it or distancing themselves from it. A prideful person who is happy with their past may attempt to relive it through various means. These are the high-school beauty queens that never stop talking about that great day when they were crowned and how they expect you to bow down to them for it. However, not everyone is happy with their past. A prideful person who is unhappy with their past will do their best to destroy it. They will abandon pictures, change their appearance, distance themselves from friends or family, whatever it takes to start a new life. They will become obsessed with being a new person. However, it is still, fundamentally, the past they are trying to control. They don't realize that God has a plan for them and doesn't care about their past. They don't need to relive or distance themselves from it, because to God it doesn't exist.

A lustful person is intent on controlling the present. We discussed in an earlier blog that lustful people were impulsive and whimsical. They feel that by acquiring things now they will make themselves happy in the present. They are not relying on God to provide for their needs, they are taking matters into their own hands.

A greedy person is intent on controlling the future. They despair and lose hope that the future will be good, so they try random things in order to make it better. At the worst, they end up committing suicide so they don't have to face a future they can't control. They don't realize that God has a plan for them, if they will accept it. They must be patient and open themselves to his Word.

I refined much of this from Ventilation. I believe that I added enough of my own exposition to make it unique, but if not...Sorry!

Football pt 2

A second reason that Football is similar to Software Development is a physical and mental limitation. There is a particular amount of time that it takes to do X and you can't force someone to do it faster. For instance, if I run the 40 in 7 seconds, then you can't will me to do it faster. I could practice and practice and probably reduce my speed, but at any given time, your desire for me to be faster will not make it so. The same is true for SD. A manager may want me to create a program will all the great whiz-bang features in 1 week, but if I say it is going to take 3 months, there is nothing you can do to make it faster. There is a physical and mental speed limit in both football and software development.

Saturday, July 16, 2005

Football

As football season approaches, I think it is worth it to investigate the similarities of a football team with a software development team. As it turns out, there are probably more similarities with a sports team than with any other. For example, as with software development, front-office management could not do what the team members do. In an assembly line, the foreman all the way up to the factory owner could step in and perform any job function. This is not so for a software development team. Front-office personnel could not replace the coaches or the players.

Each day I will try to post another similarity and also where and why and should differences exist. Check back soon.

Friday, July 15, 2005

The Talk pt 2

As always, The Talk is a wave with a beautiful white crest that is destined to come crashing into the shore. As it recedes into the ocean it takes with it the soft, silky sand leaving a garden of harsh, jagged shells.

Thursday, July 14, 2005

Team Members

There are three types of team members: Those that provide value, those that do nothing, and those that provide negative value. Positive value can be provided in many different forms. First, a person may be a productive employee. He or she may create amazing programs that always work and are easy to use. Second, a person may be a valuable educator. They may challenge the employees to grow and to think outside the box. Third, a person may have intangibles that allow them to improve the morale of the team. A negative value may also be generated in many different forms. First, a person may be a negative influence, criticizing employees for doing important things such as learning or challenging the status quo. Second, a person may be a prima donna, working in isolation creating programs that work, but that no one can understand or maintain. Third, a person may generate negative productivity. In other words, people always have to clean up this person's messes. Are you a positive or negative employee?