marcelk.org

Yes, the two are different. But when it comes to describing their quality, you can’t make blanket categorizations (i.e., good vs. evil). There are good and bad experiences at startups. There are good and bad experiences at big companies. You need to evaluate each on a case-by-case basis. And you need to know what you want. Then you can figure out which individual employment opportunity is a match for you.

I heard a story of a person who founded a startup and ran it for several years. Of course the appeal of the startup is choice of what you work on. Due to a bookkeeping error, there was some confusion with the federal tax authority regarding some financial matters. Because the startup had only two employees, one of them was tasked with resolving the issue, which took about 50% of their time over the next year. It was a huge drain on working on their true passion and very frustrating. Although anecdotal, the point of this story is to not assume that a startup you can spend 100% of your efforts working on your research or product. Because startups tend to be very focused on development, the rest of the support structure isn’t there like at a large company. A support structure can run the range of being a bureaucratic drain to being a enabling gain. In more places than you may assume, it is an enabling gain. Lacking the support structure you need to do everything yourself. Everything.

A friend who founded a startup has talked about “terminal success”. His point is that even if you are in a startup that is successful in creating the technology or product, you may not have enough mass (i.e., influence) to affect the market. You are effectively at a dead end, despite development success. Even though they got everything they wanted in terms of getting the startup going, they didn’t have enough market influence to make an impact. The pure notion of “build it and they will come” is a fallicy. This friend says, “generally it takes about 4 years to build up enough reputation to really get your business going. Basically, you will be taking a loss for about 4 years until people hear about you enough to get going. You will also need to allocate about 1/3 of your budget for marketing programs – that is programs, not headcount. Doing a startup is hard – you have to really want to do it.” This friend eventually left the startup and joined a large company because they wanted to be in an organization that already had the mass to make significant impact in the market, and that is where I met him. But there are plenty of success stories regarding startups, some of them massive mind-blowing successes. I’m not here to dismiss startups. My point is to not assume that a startup’s success is guaranteed or that it is a cakewalk.

I work at a large company, so I admit to having some bias. But in the 15 years I have been with my company, even through the dot com era, I had opportunities to learn and engage in challenging and fun and varied work, interaction with a lot of really good people, and I have been well compensated financially. And I have been able to change positions about every 2 years. So instead of changing employers every 2 years and dealing with that churn, I have been able to achieve the same desired result while accumulating deeper contacts into the company, promotions, accruing more vacation, etc. The large company gives me a mobility and new opportunities that a small startup probably doesn’t have.

There are pros and cons to both startups and big companies. There are times and places where one makes more sense than the other. They are complimentary. Your task is to analyze your situation, and determine your desire with your eyes wide open, and figure out which one makes the most sense for you.

OK, so this may not qualify as “doesn’t cost much”, (I spent $140) but it is feature-packed enough to be worth quite a bit.

Two of my three cordless phones died at about the same time, plus I started working from home more in my finished attic (3rd floor). After having a number of simple cordless handsets for my home telephone, I liked the idea of an integrated system. And now that I’ve had it for a while, it has been nice. The product is the Uniden CLX475-3. It is multi-handset system that includes a base station and three handsets. This is what I like about it:

• all the handsets communicate with the single base station. So I need only one RJ11 phone jack. The handsets can be placed anywhere in the house there is a electrical outlet for the handset to sit in a charger when not in use. The base station is plugged into my Vonage adapter, but it should connect fine to any analog service.
• you can intercom between any two handsets. So when my wife on the 1st floor wants to ask me a quick question while I’m in the 3rd floor attic office, she can ring my handset and get a high-quality audio connection without the telco and without climbing 2 flights of stairs.
• transfer a call from one handset to another, so no more yelling, “hey, pick it up, it’s for you!”
• a nice backlit display and keys. You can access the phonebook, callerid info, settings, commands, pictures (yup), etc.
• multiple handsets can join a call without making the remote party too soft to hear. This is the benefit of using only one RJ11 jack.
• a phonemail-waiting indicator on the base station and each handset. So you can look at any handset to check if you have phonemail. It’s a blinking light, so you don’t need to use the menu.
• ability to listen to phonemail or perform any answering machine function from any handset, don’t need to be at the base station.
• ability to screen calls (listen to the phonemail as it is being recorded) from any handset. You have to push a button to do that, but at least it is possible.
• decent speakerphone built into each handset and the base. Actually, the base can be used independent of any handset, so even though you have three handsets you really have the equivalent of four phones.
• standard headset jack, and a softkey to mute the handset’s microphone. This is a must for work-at-home people. My headset has a hardware mute button, so I use that since the softkey is under a menu.
• you can configure the handset and the base station through the built-in display, or you can connect the handset to your PC via a USB cable and use the supplied software. This is one of the more interesting features. With this software you can copy phonebook entries across all the handsets, pick ringtones and other basic handset configuration, select pictures for your phonebook entries that will appear when they call (callerid) or you call (outgoing phonebook) (yes, I have face pictures of family members in the handset). It also does nice things like syncing the handset clock to your PC clock. And you can rip audio from your PC as your phonemail greeting. So basically I can create a handset profile and just copy the profile to all the handsets, or set up a profile for each handset. I can also configure the base station via the handset via the software. Basically, no more tedious configuration using the handset menu or base station menu.
• a room monitor feature. This is helpful when a child is taking a nap but I want to putter in the garage, the garage handset can have a steady listen connection to another handset near the child.
• the battery life is pretty good. I can do 3 hours of conference calls and the battery meter shows half-depleted.

The things I don’t like about this system:

• It is a 5.8GHz digital system and claims to be WiFi friendly, but when I use it in my office right next to two WiFi devices it does stutter for a few seconds at the beginning of a call, which I assume is its attempt to find a clear channel. Once it stabilizes it runs fine.
• I had an older 900MHz system that had greater range than this one. This one does reach all areas of the house and yard, but trails off after I leave the yard. Since our neighborhood pool is next door, it would be really nice if I could get reception at the pool. It barely reaches the pool parking lot, but not the pool. Perhaps placing the base station on the 3rd floor instead of the 1st floor would help reach a bit farther, but I like having the default call screener (base station) on the first floor where we can hear it from the kitchen and family room. The only wishlist feature I would like this system to have is to designate one of the handsets instead of the base station as the default call screener. The system also has what they call “DirectLink”, which is basically a way to use multiple handsets in a peer-to-peer fashion without the base station – it is walkie talkie intercom service instead of telco phone service. It does maintain a two-way steady connection and is not push-to-talk. I tried it once on a road trip with two cars, but the cars had to be pretty close (i.e., tailgating close) for good reception. And to connect to the other handset required several menu operations which took my eyes off the road for too long. Using a regular push-to-talk device would work better for reasons of range and ease.

You can add more handsets to the system for a maximum total of ten, but each additional handset is $60 each from the manufacturer. So getting the initial package is a pretty good deal.

Overall I’ve liked the system.

Pride. Not invented here. I want to do it myself. I want to learn it anyway. I don’t trust it. I don’t know what it does. It doesn’t work the way I want it to. It’s not optimized for my needs.

Those are all great attempts at excuses for not utilizing something that was built by someone else. If you believe those, then you will waste a lot of time building your own infrastructure. As I mentioned in a previous post, you can’t afford to do that. The key to being productive and generating value is to spend your time on valuable things, things at the top of the value chain instead of the middle or the bottom, things that are unique that others can’t do as well as you. But to do things at the top of the stack requires things below you, call it enablement or infrastructure. So the point is to stand on the shoulders of others by using the infrastructure that they have created. If you don’t, then you have to build that infrastructure yourself, and that will suck the resources out of your project and dramatically limit your ability to progress and succeed. The same wheels have been invented so many times that it is truly wasteful. Reinventing wheels isn’t going to help anyone.

Without standing on the shoulders of others, you won’t progress at a reasonable rate. You can’t do it all yourself.

Within an organization, to beg, borrow or steal is ok, as long as credit is given. One of the greatest compliments someone can give me is to use my code. I would like credit (in the form of management recognition, financial sharing, etc), but yes, stand on my shoulders, and let others stand on your shoulders. By supporting each other we can create a stronger ecosystem that is good for everyone. We are measured on contributions utilized, not effort expended.

Maybe I’m just a bit of a perfectionist, maybe I’m not that different than the average person. I like things to work just right, usually by my definition of “right”.

So sometimes I feel compelled to spend time tweaking something to work just right. Sure, it worked good enough before, but it wasn’t perfect. So instead of moving on to something more productive I waste time trying to squeeze out that last level of perfection.

You may hear business people talking about ROI. It is Return On Investment, figuring out if what you are investing in is worth it, or if it would be smarter for your limited resources to be invested somewhere else that will give greater returns. Generally the ROI for “tweaking for perfection” is not worth it. There are times when “good enough” really is good enough, and it may be more frequent than you think. Yes, there are times when perfection is needed, but before you go for that you really need to think critically about the real requirements. There isn’t time to make everything perfect in every circumstance.

I was watching a few students on a development team. These two students had different opinions over how a piece of code should be done. But the assignment to write the code was given to one of the students. The student wrote it, it worked, and was checked in to the repository. Later, the other student analyzed the code that was written by the first student, changed it, and checked that in to the repository, all without talking to the first student. Of course, when the first student discovered what the second student had done, there was some friction between them that took a while to resolve.

There wasn’t anything wrong with the original code from the first student, it worked and met the specification. My objection with the second student was the time spent re-doing code which was already sufficient. That was time that could have been directed into something more productive that could have advanced the team. The first version of the code wasn’t done the way the second student wanted, but it met the needs of the project. There was a loss to the team both in terms of time and teamwork.

What it basically comes down to is trust. In a team you have to trust other people. Yes, you need to know if the other person is trustworthy. Assume they are unless proven otherwise. But if they are then you need to exercise that trust. If you don’t exercise that trust then you’ll need to do everything yourself. And you don’t have the time for that and that is not the definition of a team.

This is one of the grand failures I’ve had that I would like to save others from repeating.

The team was working on a big project that was going to add a significant amount of new automation to an existing business process. Had all the business data been in a relational database, it would have been easy. But the data was spread across all kinds of storage, including flat files and mainframes. So we spent a lot of time on a data store abstraction mechanism. And we wanted a rich client but had to support multiple UI types, so we wrote multiple clients using multiple UI toolkits. So did we have time left over to actually automate the target business process? Not really.

I can image someone saying this to me: Ha ha! You fool! You fell victim to one of the classic blunders! The most famous is never get involved in a land war in Asia, but only slightly less well-known is this: never write your own infrastructure when your project has a deadline! Ha ha ha ha ha ha ha! Ha ha ha ha ha ha ha! Ha ha ha…

That was back in 1994, so I could claim a small excuse in that there wasn’t a lot of off-the-shelf infrastructure available then as compared to now. But even then we were reinventing wheels that already existed elsewhere. So the moral of the story is to spend the vast majority (if not all) of your effort on the application instead of the pre-requisites for the application. You’re not paid to build pre-requisites, you are paid to build applications. Users of the application don’t care about the infrastructure, as long as it doesn’t adversely affect the application.

This also might seem common sense now, but it hasn’t been happening for long. As I mentioned in my previous post in this category, the idea in the 90’s was if you wanted to make money then you had to have exclusive control. But having exclusive control means that only your customers will be using it. And if it is new, potential customers may not want to commit to that technology/product until other customers are already there to make sure it runs well and will be long-lived. This is why there was so much fragmentation.

The scare in being open is that a provider’s high-profit item can be commoditized. I believe that commoditization is inevitable. You may try to delay it, but it will happen eventually. The commodity line is always rising. So embrace it now, and instead spend your resources working on high-value items above the commodity line. You will probably need to periodically exit business areas that are falling below the commodity line and start fresh on something higher up. The one thing constant about the I/T industry is change.

Eclipse is probably the best example of a proprietary thing that was turned into an ecosystem. Many people think of Eclipse as a Java IDE but it’s really an application framework. So applications other than a Java IDE can run inside it, for example object/business modeling, administration, groupware/email, etc. And it has the capability for running plugins developed by 3rd parties, one site alone lists more than 800 plugins available.

IBM could have held on to Eclipse as a proprietary item and not released it as open source. But I don’t think it would have reached the same level of use in the community had it done so. By making it open, the number of participants has greatly increased. Quoting Metcalfe’s Law, the value of the network is the square of the number of the participants. When you get enough participants across a broad enough set of sources, the value becomes compelling enough that people will want to participate. That is how you get to have a community of adopters and contributors and hundreds of 3rd-party plugins.

When it becomes an ecosystem, instead of building raw elements and infrastructure, you can focus on your specialties, or in other words, work higher up in the value chain. Instead of writing GUI widgets, you can do what you are good at and use the GUI widgets. Building things higher up the value chain means more capability for the customer and greater profit margins for the provider and a stronger industry. It’s better for everyone. Even when an IBM competitor like BEA joins the Eclipse Foundation, not only is it OK, it is good. It means the ecosystem is growing.

This seems so common sense now, but back in the 90’s it was exactly the opposite. The thought was that in order to make money you had to have control, and to have control meant it had to be done in a way that no competitor could access it or duplicate it at a lower cost. Now in this relatively enlightened age we recognize that the network is where the value is, a rich ecosystem (including competitors) is how revenue grows, and standards are how we create a network and an ecosystem. We compete on implementations, but we cooperate on standards.

So the corollary now is to use standards and off-the-shelf components whenever possible. Sure, they won’t be optimized for your purpose and may not do it exactly as you’d like and there may be some not-invented-here feelings, but you can’t afford to optimize everything. Given that there are enough computing resources available now (CPU cycles, storage, network bandwidth, etc.) you can let things be un-optimized. It is OK to waste some resources. That is what is new.

I just finished developing a large application with a team and we didn’t optimize anything. Then in our test cycle we did see some significant performance problems at a certain scale. Analysis identified that by optimizing how we stored one object class we could get rid of the performance problem. Everything else worked fine. So we got an entire product performing well by optimizing just one thing. Just one thing, and all it took was about 50 lines of code. Keeping everything else un-optimized keeps the complexity down, and the complexity is where the real cost is.

Want to use that development framework so that you can work faster? Want to use that library that provides some good function? Want to use that technology for a desired effect?

All these things are helpful and will do something for you. The cool thing is that in this world of open source they don’t cost anything, right? Wrong.

While it may be true that there might not be a direct up-front financial cost for acquiring those things (assuming they are gratis), it is blatantly false that there is no back-end cost for those things. Everything has a cost. That cost may be in the form of time to integrate, increased risk, footprint size, complexity, limitations introduced, bugs inherited, intellectual property liability or contamination, or something else.

Don’t misunderstand me, I’m not suggesting that you always avoid using things. What I am suggesting is that you always determine what the cost is, and evaluate if the benefit provided by that thing is worth the cost. Do not assume you can get the benefit without the cost.

Nothing is without some kind of cost. Nothing. There are some good deals, some bad deals, and some so-so deals. Just be conscious of what you get yourself into.

I am selective about what technologies I use, because I recognize that everything has a cost. Everything. Some things are worth the cost to me, some things aren’t.

One of those things that aren’t worth the cost is cable tv. Part of it is that I am involved in enough things that I don’t have the time to watch much tv, but it boggles my mind why anyone would pay $60/month (a.k.a. $720/year) for the purpose of watching tv shows that are still full of commercials. With all the chatter about free Wifi spots has everyone forgot about a mature technology that allows for free tv reception? It’s called an “antenna”. Hook up an antenna to your tv and you can receive sometimes a dozen channels at no monthly cost, ever, with no contract, for an unlimited number of tv sets in your household. It doesn’t always need to be on a 30-foot-high pole in your yard, a regular pair of rabbit ears in your living room may suffice. Yeah, I don’t get the Discovery channel or HGTV, but if I did it would probably introduce sufficient strife in my household anyway. Outside of that, generally it seems that even with 100 channels, there still isn’t anything worth watching.

Here are some sites that a friend gave me that you may find helpful:

• Consumer Electronics Association AntennaWeb: shows the distance and orientation between the broadcasters and your residence (this is cool)
• Plain Money: answers some basic questions about antennas
• HDTV Info Port: more answers to basic questions

That said, one of the things that is worth the cost is my Tivo. For the few things I do watch on tv, I never watch live so everything is time shifted. Not having to deal with a stack of tapes is wonderful. I’m on the $12/month plan with Tivo. (I’m not a fan of subscription services, but I understand that is how the hardware cost is amortized since I paid only $100 for the device.)

So while talking with a friend recently about my Tivo, they were aghast to learn that my Tivo was hooked up to an antenna instead of cable or satellite tv. “Is that even possible?” they asked. “Sure it is,” I replied. “Works great.” I have full functionality with my Tivo hooked up to an antenna and a broadband connection. The Tivo box has a coax connector on the back that actually is labelled “Antenna”, and it has a tuner inside. You don’t need satellite or cable tv for Tivo. Just connect it and go.

The nature of software engineers (as one myself, I use the term loosely) is to add. Start with something, and add more features, more data, more configuration (but not generally more documentation). We have the best of intentions, trying to make our software more valuable and more powerful.

As developers it is relatively easy for us to understand the design, know how features ought or ought not to be used, and the nuances of the configuration. The builder understands their own house. But can the same be said of the end user? Generally we develop software for users, not ourselves. Are the users left drifting in a sea of compexity unable to get their bearings?

Don’t get me wrong, I love Unix and grew up on it. But I have heard new Unix users complain about it being difficult to use. My best rebuttal is, “Unix isn’t user-hostile, it is expert-friendly.” How many times can something similar be said of systems we build every day? It has been my experience that each time we add something, it causes other issues which in turn require more things to be added. It can become a death spiral.

The Macintosh goes a long way to making Unix usable. Linksys and Tivo do a good job of making Linux usable.

If your software isn’t usable, people aren’t going to use it. And if noone uses it, then you are wasting your time developing it. Above all, it has to be consumable.

Remember the 80/20 rule and put it to practice. That last 20% of function is going to be really expensive, add a lot of complexity, and probably not be needed by the majority of users. Maybe you are better off without that last 20%. Keep your scope as small as possible, and don’t let it creep larger. It will definitely want to creep larger, you will have to purposely push it back.

Have good defaults, and have your software try to do the right thing automatically. How many of us want to just run the installer and crank it up without reading a 2-inch thick manual? It should do something meaningful without hardly any requirements on the user. If you absolutely need a configuration setting like a database name, figure out how to probe the database server to get a list of the available databases, and either let the user pick the right one from the list or (better yet) probe the database schema to see if you can automatically figure out which one should be used. If you need a database password, ask for it in the UI instead of requiring the user to edit some configuration file buried deep in the filesystem that is described only on page 183 of the manual.

Remember the golden rule for documentation. If you were new to this, what documentation would you want to have and how should it be organized? This applies not only to users, but also co-developers (meaningful comments, architecture descriptions, etc.).

As developers we sometimes pride ourselves on the complexity of an item we’ve built. It is human nature for us to think that bigger is better. But in the CS world, it isn’t. Elegant is better. And elegant is usually about right-sizing instead of super-sizing.

Take a look at how Agile methodology and XP describe it. Make a conscious decision of what you are going to exclude, and let it go without feeling guilty. It is impossible to please everyone, so just get used to it.

If you do it right, it should be simple. And building a simple solution usually requires multiple tries. But it is better for the developers to expend effort than for the users to.