Author Archives: bill

Strategic and Free

I worked for nine years at a major software company specializing in computer aided design software.  During my tenure there, I worked on three major software products which were sold to end users.  The first one, a diagramming products was priced at $199 (or was it $299) and was competitive, both in functionality and price with our competitors.  Sales were ramping up slowly when our competitor was bought by another huge and pervasive company.  This made our product’s future very bleak and it was dropped soon after.

Our next product was an architectural product.  Our competitors charged $500 for a very cool and fairly functional application.  When we finally came out with our first release, it went to the company’s pricing committee, which decided that we should charge $900 (our marketing guy had recommended $500).  It was a cool product and some functionality was better, some not as good, as our competitor’s.  However, the pricing was totally out of whack.  At $900, the decision to buy needed more levels of approval and couldn’t just be purchased on a whim by most architects.  Conversely, a $500 product was much easier to justify and purchase.  After a couple of years of good reviews and slow sales this product was dropped.

The third product was a view and markup product, priced at $199.  It was just what the market needed and wanted and sales were setting records at the company.  Eventually, however, it was decided that it was an important strategic product and should be used to help the company’s general bottom line.  It was given away for free as part of this corporate strategy.  While this was fine for the company, it wasn’t so great for the group that developed it.  When your group produces a toolkit, utility, or other free product, someone is eventually going to notice a red column on the corporate budget.  This is your group, employing many developers, but not providing any direct income.  It’s difficult to quantify “strategic product” on a balance sheet and the memory of why your product was so important in the first place is soon forgotten.  When lean times roll around, what do you think is the first group that’s going to be cut?

It’s sad and unfortunate, but being attached to strategic and free products/projects in your company may eventually put you at risk for being first on the chopping block.  If you’re on such a team, you must continually remind upper management why you were created in the first place and why you continue to justify your existence.  Failure to do so while only likely result in the decision to strategically eliminate a negative on the balance sheet, making your executive look good in the short term, regardless of the long term.  But, when did the future ever influence an executive’s bonus?

What Shows and What Doesn’t

I was talking to a friend, Dave, at a party this summer.  He told me how the company he worked for (we’ll call it ABC Corp.)  was working on a contract for another firm (we’ll call them OtherComp).  ABC spent a great deal of time working on the database and software design for this very large project.  They wanted to be sure that they got it right.  However, 6 months into the contract, a competitor (EnemyCorp) approached OtherComp and said they could do the job better and quicker.  OtherComp looked at what ABC had produced so far, mostly design documents, and decided that they’d see what EnemyCorp could do.  EnemyCorp dived right in and started coding.  They produced prototypes and according to my friend were definitely not doing a great job on the whole project.  He suspected that after a while, ABC would be called in to clean up the mess that OtherComp bought from EnemyCorp.

I told Dave that this sounded pretty typical and wasn’t in the least bit surprising, actually.  You have to feel out your customers to see what they’re looking for.  This customer wanted to see something.  Not a document.  A working application.  Something they could look at and “touch” to determine how they liked it.  Something they could point to and comment on.  Tangible progress.

With any large project, there’s a need for solid design work.  However, some customers don’t have the patience to wait months or years to see the real thing.  Plus there’s no guarantee that your design will be perfect either.  For some projects, perhaps a prototype that goes along with the design work (or as some of the design work) would be more appropriate.  This could go a long way to convince your customer that you’re really making progress and keep them from getting distracted by another company.  Watching out for your customer’s best interests should be at the forefront of your activitites, but that might mean watching out for your own interests as well.

Signs of the Times

I went to visit some friends at my old company earlier this week. By the end of the week, most of them had been laid off. It’s both a sad testament to the times we’re going through and the short-sightedness (and stock-mindedness) of executive management.

The company in question (let’s call them BigCorp) had grown by leaps and bounds in the past couple of years, both due to a number of large acquisitions and massive hiring. One of the companies they bought was a 900 person contracting company in China. BigCorp was looking to grow their presence in China as the Chinese government will be more inclined to buy software from companies either based in China or at least with major operations there. As a result, they were moving a lot of their development work to China. Unfortunately, the developers there lack experience both in programming and in the programming domain. Like most new programmers, they tend to apply brute force to problem-solving and they tend to screw up frequently. The programmers in America spend a lot of their time fixing these problems, but since the software gets produced, upper management doesn’t think anything is wrong.

Well, now some more of those American programmers are gone. They won’t be there to watch after the software that’s produced overseas, but it’s not likely to be noticed. I decided a long time ago that the implications of top-level decisions is often missed and that one’s legacy at a company is forgotten in relatively short order. Will anyone remember that you were the one who used to catch all of the problems with the software before anyone else noticed? Probably not.

Legacy aside, BigCorp set up this particular group of developers for the axe a couple of years ago. When they first started on their last project it was to be an inexpensive product that would be part of the corporate strategy in making BigCorp’s software more ubiquitous. Eventually, BigCorp decided that this product should be free so it could be even more ubiquitous. Well, when push comes to shove, eventually someone comes along a couple of years later and they see a group that doesn’t make any money and a bunch of programmers that get paid a lot to produce it. If it comes to cutting that group versus another one that produces money, which one would do you think is more likely to get chopped?

In the end, it results in unemployed programmers one way or another. The most important thing is that as demoralizing as things get when you’re on the bloody end of the “axe”, you have to remember that you were valuable once and will be again. Take a few days to sulk and grumble, scream at your dog that it’s just not fair, then dust yourself off and get on with your next chapter. Polish up the resume, start calling all your employed friends and family, and get the names of people inside companies that can hire you (go around the human resources department). Sure it sucks that you have to go through this (I’ve done it several times due to lay-offs and corporate downturns), but each new job offers a chance to experience something different, make new friends, and learn something new.

The Death of Boxing

I was talking to my father a few months ago when I posed this question. Are we watching the death of boxing as a popular sport and if so, why? I suggested that boxing started to decline when public broadcast turned to pay-per-view and private broadcasting, such as closed-circuit television. Back when I was a kid, all of the major fights were on national television. I can still remember Howard Cosell calling the Ali, Frazier, Norton, and Foreman fights. Back then, everyone knew who the heavyweight champion of the world was – and there was only one at the time, not five. But, money gets the best of everyone sooner or later. Promoters decided that they could use boxing’s popularity to leverage revenues by charging people to watch it. In the short term, this worked great. Over the years, however, I think people slowly lost interest because of this. The promoters started setting a bar that you had to hurdle to see the fight. Eventually, you have to decide whether you’re willing to shell out $50 to watch a fight on TV. If you know the fighters, you might decide to invite some friends over and split the cost and it turns into a small party, like Sunday afternoon football.

However, these things can spiral. Some people won’t go over the hurdle. They start to lose touch with the fighters. Popularity declines a bit. Coverage in the newspaper gets smaller. Coverage on TV used to be in the mainstream stations even for the weigh-ins. Now, if there’s coverage, it’s on ESPN. That may be the best place to report on it, but it’s yet a smaller number of viewers than your local ABC news sports report.

With every hurdle and every dilution comes a smaller market share. Combine this with other interests, like mixed martial arts and the UFC, and you’ve got a recipe for decline. Once you start to coast and don’t invest in your product, you can bet that someone else will come along and take the interest away.

This is Software Development?

I was reading Jeff Atwood’s post on Programming: Love It or Leave It which was derived from a Joel Spolsky forum entry. This got me thinking about some of the responses and some of my own experiences. I’ve mostly worked on products as opposed to IT departments. As Joel points out in one of his responses, “[you’re] going to get more out of computer careers if [you] work in a product company.” This is because products tend to be longer life projects, tend to suffer less from budget cuts than internal IT projects, and mostly because they involve more design and creativity components as you have to try to appeal to customers who don’t have to buy from you. In a product company, you’re more likely going to have to produce software for sale as opposed to maintaining databases, hardware, or software, or another of hundreds of mundane tasks.

There are so many possibilities in the computer programming world. When I talk to people about what they’re looking for in their next job, I point out that there are many different possibilities. Small product start-ups, small companies with established products, large product companies, web-site companies, web-site design and consulting companies, large and small embedded software companies, IT service companies, non-software companies with IT departments, universities with research programming needs and IT needs, and many, many more.

Each one of these places offers different kinds of work. Some people have said that there is a shift in programming going on today. My friends who work for a large software product company spend a good amount of their time designing code for people in China to write. They get software back that may or may not work well and may not be up to par. Then they have to either request changes or fix it themselves. They tell me that it would be easier and more efficient to simply write the code themselves. Either way, this is what’s happening at that company and they don’t believe it’s going to change any time soon.

If you don’t like what you’re doing there are several choices. Do something entirely different and quit programming. This is the extreme approach. Alternatively, find a different kind of company or software. Your experience is transferable, but you may have to convince potential employers of this. Doing some personal projects can help fill in missing job experience. For example, if you’re in web programming and are looking to move into a product atmosphere, download a Java environment and develop a small shareware or freeware application. You’ll have something tangible to point to and you’ll find out whether you really like doing that kind of development work.

There’s a world of software out there, some of it hiding where you might not suspect. Do some web searching and personal networking. The economy may stink right now, but there are many companies that still need to get work done and there are jobs out there if you dig enough.

Finding the Love

I’ve been doing this for a long time – over 22 years, in fact. A couple of years ago I started to lose the love of programming. What happened? It was a conglomeration of things. I worked for an idiot boss for a year. I worked on a large project that was very touchy and was full of spaghetti code. Changing something that fixed your problem always caused something else horrible to happen. Probably the worst things were that I no longer felt like a vital part of the decision-making process and had been relegated to being a cog.

Being a small cog in a large machine is not unusual for a programmer; some people actual prefer this kind of role. They enjoy going to work, being given a set of tasks to complete to given specifications, and going home at night without worrying about what’s next. However, this doesn’t suit everyone and it sure doesn’t work for me. I need a little freedom. Freedom to design my code, my UI (or at least have some feedback into it), my platform, my tools, and my environment. After working in C++ for many years, where everything is hard because hardly anything is built in, the constant struggle to get a simple job done and the fact that everything takes days or weeks can get to you.

So, how do you find the love again? First, try to regain some control over your domain. Lobby for some design input. If your product is defined and designed by a product manager, marketing group, or product designer, ask to be included in the design discussions for the next release. It never ceases to amaze me what assumptions are made about implementation by people who don’t actually implement things. It also boggles the mind how complicated some people can make even the simplest tasks because they think it will be more elegant. Users like to use slick, beautiful user interfaces, but they also want to get their jobs done as quickly and easily as possible. How many UIs have you used that seem like it takes 5 steps to get somewhere when 1 or 2 is all it should take?

Second, start to take control of your environment. Are you using a reasonable IDE or editor for your coding? There are lots of choices, but whatever you pick should be helping you do your work more easily. Do you have help with formatting, automatic code completion, and UI development? If not, and you think it would help, get a hold of something better. Convince your boss that the money spent on better tools will cost less in the long run because it will save you time.

Third, if you find that every task in your application looks like you’re slogging through the jungle or that you have to constantly build things that just ought to be there already, make it happen yourself. Change your mindset for a minute. Start thinking about what kind of functionality should be just built into your environment. Could you use a easy interface to file saving and loading, a better string library, or something else? Rather than simply building it into your next piece of code, think about making it part of your new toolkit. Turn this functionality into a library or module of its own. You’ll end up with something more reusable and that will help you and the rest of your team for a long time to come. Be sure to document it with some comments, a few examples, and a brief overview. I’ve found that as soon as I start to write a little documentation on something (even if it’s not extensive documentation) that I realize that I could make the design easier to use and understand.

Chances are, you may already have code in your system that could be reused if were simply packaged better. Instead, people just cut and paste code or have to figure it out on their own. Refactor the code into a toolkit and users of the toolkit. Future coding will be much easier.

Have you ever noticed that every time you have to use some code, you have to read the function or method definitions or even the code carefully to figure out what it does. These are great targets for a little refactoring, commenting, and light documentation. Even some simple function renaming may make things clearer and easier to use.

Taking control of what you’re doing and how you do it, can help you start to find the love again. Try it.

Shameless Promotion

I wrote a while ago about how writing software and writing a book were similar. It’s my pleasure to announce that Design, Code, Test, Repeat: Your Instruction Manual for a Great Software Career is now available! Go here for more information.

Delete On Exit

A couple of days ago, I was working on some code. I had created a few temporary files on disk and needed to delete them. I was going to work out a scheme for recording the file names and hooking into an exit routine to delete them. I went to look for the delete file command in Java and found something brilliant: File.deleteOnExit.

I was thrilled and stunned to be confronted with the answer to my problem. All I had to do was call this function and Java would take care of the rest. It doesn’t get any easier than that. This is just one reason that I don’t agree with Jeff Atwood on his assertion that you must be a good typist to write code. If I had blindly started writing this utility, I would have added a few dozen lines of unneeded code. However, that’s not really the point here, just a corollary point.

My real point is that including deleteOnExit was brilliant. It’s just one example of why I love Java for writing an application. I’ve written loads of C++, and a little C# (but, not enough to know all of the hidden functionality). What amazes me is that I’ve been able to make incredible progress on my application than I would have considered possible in C++ in more than twice the time. Part of it is due to Java’s integrated UI, graphics, and table functionality. In C++, there’s an object oriented language, some utility classes, and the Microsoft windowing and graphics stuff that’s really old and poorly designed. In C#, at least there’s some integration of these things as an environment. But, that’s still not the point.

Getting back to the point – including useful functionality as part of the package saves people time. It’s part of picking the right tool for the job. It’s why you should write a script for repetetive programming tasks. It’s why you should refactor your code to create as many utility functions for other programmers to use. It’s why the Extreme Programming mantra you’re not going to need it is only partially on the mark. It’s why you should always think about how to make your code reusable. It’s why you should try to write as little code as you can to do the job correctly, creating and using the tools available to make coding easier.

The next time you’re writing some code, think about whether there’s a way that you can make it easier to use. Including deleteOnExit is just one example of saving thousands of users time because one programmer thought to add it to the toolkit.

Being There

Today’s world of software development is decidedly more global. Outsourcing and offshoring is common because every knows “it’s more economical.” While I won’t debate that last statement (I’m not really convinced it’s more economical), it is simply a fact of life and not really the point of this particular post anyway.

Currently, I work from home. I’m doing some contract programming work for a local company. I’m developing an application that they had had an intern start. The intern had spent several months working on it and it was allegedly nearing the stage where it might be considered sellable. As it was used mainly internally, the requirements for style, bug-proofedness (is that a word?), and functional completeness were a little lax.  And so I come to inherit a piece of code written a couple of years ago by an intern.  Most of the code was unusable due to a complete lack of comments, usefully named variables, and code that wasn’t full of bugs.  Nonetheless, I was able to lift some ideas and one piece of code that undoubtedly will save me some time, but is nearly unreadable.

But, that’s not the point of today’s post either; it’s just some background.  The real point of this post is maintaining contact with your employer, colleagues, manager, etc. (I’m going to group these people into a term called “work folks” for future ease of reference.)  In other words, being there.  If you work remotely, getting face time with your work folks is difficult, but not impossible.  There are several options for increasing your visibility.

  • Take a trip.  There’s really no better way to increase your visibility than actually being visible.  Take your laptop and find a desk in the middle of the place if possible (rather than a secluded conference room.  Become “one of the guys” for a week or two.  Have lunch with everyone that you can and get to know them a bit more personally.
  • Make a phone call.  If you can’t be there, at least pick up the phone occasionally rather than relying totally on email, which is far less personal.  Conversations have more range of direction that they can flow in due to their interactive nature.  The scope and types of things you can find out in a conversation are far greater than what you’ll get in an email response.  There’s also a far lower likelihood of being misunderstood or having to ask for more clarification in a followup email and the turnaround time in a conversation can’t be beat.
  • Communicate regularly.  Trips are expensive (depending on distance), phone calls aren’t always easy due to time zone issues and meeting schedules.  If nothing else, a regular email update will keep you in the minds of your work folks.

Whichever mode you pick, keep up a regular pace of communication so you stay on the radar of your work folks.  It will make you feel like you’re a part of the team and make the team feel like you’re one of them as well.

Version 2 – Now with Chipotle

Have you noticed that chipotle is the new baking soda. Back in the 90’s, you couldn’t turn on the TV without seeing a commercial talking about how they added baking soda to make the product better. Crest toothpaste – now with baking soda. Try our laundry detergent – now with baking soda. Goodyear tires – now with baking soda. Arm & Hammer Baking Soda – now with even more baking soda!

Well, today, chipotle is the new baking soda. You can’t turn on the TV without seeing a commercial talking about how they added chipotle to their chicken/steak/hamburgers/barbecue/broccoli. Although I haven’t eaten out much recently, the idea is that chipotle will give the food an extra kick of flavor that will delight you.

When I was writing software in the 90’s, I used to talk about advertising our next version of software as “Version 2 – now with baking soda”. But, since we’re living in the year 2008 where chipotle is the next big thing, I’m recommending that you add it instead. That begs the question, “How?”

Now that I’m doing some private contract work, my work attitude has changed considerably. I’m no longer working for a large, bloated, cash-laden company. It’s not like I didn’t give every company my best ideas and effort, it’s just that an environment like that tends to have long development cycles, lots of waiting for specs and testing, etc. In other words, it often lacks a sense of urgency and a sense of true ownership and responsibility. Now that I’m working for a friend, I have a renewed sense of all of these. One thing that this is leading me to do is add chipotle to my software.

When I first sat down to talk about the application I’d be working on, I had tons of ideas, but wanted to make sure that I could continuously send software updates to keep my client aware of my progress. I also knew that this was a first release and that my client didn’t want to spend a fortune on it. On the other hand, a first impression is a lasting one, whether it’s your software in front of a customer, or your work for your client. So, I regularly send updates and when I do this, I outline a list of the new functionality I’ve added and ensure that everything works well. In addition, I try to add a little chipotle with every update. Sure, it’s supposed to show something on the screen when this happens, but isn’t that dialog sharp looking? Sure, it’s going to have standard printing functionality, but how about this special option that automatically does some setup that will save you tons of time?

When you’re working on someone else’s dime, it adds pressure to stay focused on task. It means not wasting time (or at least not charging the customer for it). It means adding some chipotle, especially if it doesn’t cost the customer anything extra.