marcelk.org

For my CS degree, I was one class away from getting a math minor. Yet in the 15+ years since then, I’ve never used all the math I learned. As a result, I’ve forgotten most of it. So were all those math classes a waste of time? No. I think what the CS students were supposed to learn from those classes is a way of thinking, an approach to problem solving, and overall training. There are some industry jobs that require heavy math, and others that don’t. I ended up in the latter category. I’m not a manager, so I don’t have that excuse. So my point is to not be surprised if you find yourself math-less too.

Specialists are everywhere. It may be a person that focuses on a particular technology, a particular product, or a particular use case. That kind of focus is good and is needed. But a world only of specialists is not a good thing.

Some of the most successful people I’ve seen have a broad array of knowledge. They definitely are not experts in everything, but they know enough to get around a little bit. What they don’t know, they can look up or route. They have specialties, but they also know a little about a lot of things. They know enough to recognize patterns and remember history. You may think jack of all trades, master of none, but they do have some areas of focus that they can lead in. But they have had a varied past without purging their previous lives. Those people can apply concepts from other areas to the problem at hand.

It has been mentioned by others that nothing we go through is new, it is just history repeating itself. For example, many of the recent advances in personal and mid-range computing are lessons learned from the mainframe 30 years ago. There are definitely new ways in which technology can be applied. People who recognize patterns and remember history have an advantage in determining those best ways to apply. Combining invention with insight, meaning how to apply the invention, is the way of innovation.

Broad knowledge also applies to understanding the context of any situation. The more you know about how another part of the system works (i.e., related component, customer process, etc.), the more optimal your part can fit with the rest of the whole.

Broad knowledge also applies to careers in general. You should get to know something about all the parts of a product life cycle: customer requirements, design, development, testing, support, sales, etc. This means working with all different kinds of people in different circumstances. With diversity comes capability.

Particular skills combined with a broad foundation is key to success.

Fully keeping up with technology is impossible. You need to learn how to learn, especially just-in-time learning. You don’t have to take a class to learn. Here are some ways to learn:

• Wikipedia. This may sound lame, but it works quite well. So picture this scenario: you are in a meeting, and in the discussion suddenly there are terms and acronyms you’ve never heard before. Everyone else seems to know these things except for you. You are about to get left in the dust. You need a quick explanation of what that stuff is. What should you do? Do a quick search on Wikipedia. The entries for technology and pop culture are especially well written, but I don’t care about pop culture. Read the first paragraph or two of the Wikipedia entry and you are back in the game.
• Play. Budget some time to explore some areas you’ve always wanted. You may be surprised at the payoff, even though it may take a while. I got a wonderful job because of something I did as an unrelated side project. It doesn’t have to be related to your current job responsibilities. But be careful not to take noticeable time away from your current job.
• Follow links. Click one level deeper than you usually do. Do a little exploratory reading. Not only does it give you more context, the cool thing it gives you is more relationships.
• Listen. Spend time listening to people outside of your core area. You’ll be surprised at what you can apply from them. You will see patterns emerge that cross multiple areas.
• Read. I’ll explain in more detail in a later post, but consume lots of summaries. Go for breadth instead of depth.
• Ponder. My best ideas come either in the shower or driving in the car with the radio off. Take time away from work and give your brain some space to wander around unguided. For me, this happens when the screen and speakers are off.
• Get a devil’s advocate. Take your favorite topic that you believe the most in, and let someone pick it apart as if it was a series of mistakes. Contrary to what you may think, there is always more than one way to do it. You may find a better way. Unpleasant as it may be, being pushed and challenged is a great way to get better. And some of the best lessons learned are the lessons that come from mistakes. Pain has an amazing way of improving your memory.

If you thought you were done learning when you graduated from school, think again. In the I/T field the learning never stops. The question is: can you keep up?

Working at a large company, one of the first thoughts to enter many people’s mind is bureaucracy. Many people consider bureacracy as inherently bad, the term is often used in a negative way. I had a friend who said basically if you aren’t doing something every day that could get you fired, you aren’t taking enough risk. Although it is good to challenge the organization so that it ends up doing the right thing, that quote is a bit extreme for me especially for organizations that are stable. And implied in it is that you ought to always be pushing against the bureaucracy. You’ll find that you can burn a lot of physical and emotional energy if you are always pushing against the bureaucracy and view everyone else as a bunch of idiots. That isn’t healthy for your employer, your project, or yourself. If you are always pushing against the bureaucracy, that is a sign that something is wrong – it might be your organization, or it might be you.

Bureaucracy isn’t always bad. There are places where bureacracy can have positive effects. Rules and processes exist for a good reason: they help the organization to scale, and frankly they help to prevent problems that have occurred in the past so they aren’t repeated. Bureaucracy also needs to be balanced such that there isn’t so much of it that it removes the opportunity for personal judgement. There are places where it gets out of balance, but don’t assume that mere presence implies out-of-balance. On the flip side, we tend to be naive about how complex the world really is. Although simple is good, we shouldn’t oversimplify it to the point that we make poor decisions.

Large processes in an organization are often segmented into smaller processes which are carried out by individuals. So one of the side effects of a bureacracy is that certain people have responsibilty for parts of an organization’s process. If you can figure out who owns which part of the process, (this is the good part:) you can get the organization or those owners to do the process for you. Basically you can get other people to do things to help your project.

Here are some examples of that:

• Write the product documentation all by yourself (most programmers are poor writers) vs. a trained Information Development staffer (technical writer) writes the documentation for you.
• Be aware of and install all the patches for your operating system and application, do backups, manage licenses, etc. vs. use the servers provided by the I/T department.
• Get sued vs. work with your organization’s lawyers to maintain intellectual property protection.

Now the part that many people have a difficult time swallowing is that the process usually needs to be done the way that the owner wants, not the way you want. That is probably because the owner has a lot of experience and knowledge for that process and has figured out how to minimize risk for that process, whereas if you were doing it you would want to minimize the effort instead of the risk. As I’ve mentioned before, there is a cost for everything. In this case the cost for someone else doing the process for you is that it needs to be done their way. And I’m going to propose that in most cases that cost is worth it. Get the bureacracy to work for you. Use your organization as an asset, not a liability. The cost may be some lost flexibility, but if in the end you get more done that applies the experience of experts, that is probably a cost worth paying.

So, you’ve graduated from school and are starting your software development job. Will you be spending 100% of your work time inside of emacs and Eclipse? Definitely not. I suspect you’ll spend less time in emacs and Eclipse than even your lowest estimation. Is that bad? Not necessarily. It depends on what your employer really wants from you.

Generally, as a software developer you are hired to do more than just write code. I would expect that if an employee did nothing more than just write code, their career path would be pretty short.

Here is a list of tasks that a software developer may be involved in during a product cycle (this list is off the top of my head, is not complete):

• identify market opportunity
• identify customer requirements
• identify competition
• obtain funding
• scope product function
• identify user scenarios and roles
• identify existing technologies to fulfill needs
• acquire or research missing technologies
• size the items in the product plan
• determine other project plan elements such as milestones and dates
• acquire employees with needed skills
• build infrastructure for development and test
• identify high-level architecture
• identify mid-level architecture/modules
• organize the development team
• develop the code
• resolve merge conflicts
• report to management/funders periodically regarding the progress
• respond to changes in customer requirements
• respond to changes in competitors’ products
• respond to changes in technology shortfalls
• prepare the code for internationalization and accessibility
• add diagnostic capability (ie, logging)
• develop functional test case plan
• write, run, and debug functional test cases
• do the same for the performance test cases
• identify performance bottlenecks and implement optimizations
• create customer documentation
• create and test install scripts
• verify release candidate install images
• create live demos
• give live demos to first potential customers and analysts
• triage customer problem reports as product bugs, customer mistakes, or environment incompatibilies
• recreate and fix product bugs
• create and package fixpacks, update product documentation
• identify long-term support plan
• provide in-depth training and documentation for support staff
• respond to customer issues that support staff can’t handle
• respond to requests from high-end customers to add customer-specific features to the product
• participation with standards bodies
• interfacing with lawyers regarding writing patents, embeding/licensing technology from other organizations, avoiding source code contamination, etc.

Did you notice how only one of those items says “develop the code”?

You may think that most of these items will fall to someone else in your organization. While that may be true in some respects, you will still be affected. For example, the item “obtain funding” may fall to you in the form of “build a mockup demo that the boss can show to potential customers/funders”. The item “identify competition” may fall to you in the form of “figure out what this competitor’s product does to see if really does what it looks like”. The item “organize the development team” may fall to you in the form of “figure out what everyone else is doing so there are no holes, no overlap, and that the interfaces will connect appropriately”.

Another surprise for most people: if products are being well supported and used by organizations, the cost of support is greater than the cost of developing the product. Yup. The first time I heard that I was really surprised. The majority of the cost is in supporting the product, not in building it from scratch. You may take shortcuts in support to drive that cost down, but recognize that as a shortcut that may eventually cause that customer to defect to a competitor.

Understand that software has a lifecycle, it’s not just about “develop”. It is going to need a team, infrastructure, and processes. You will be involved in those things. That is most likely part of what you are being paid for, and is important to your employer and customers.

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.

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.