Friday, February 19, 2010

Thoughts on software development

So with the lull in recent interview activity, I've been meaning to write down a few thoughts about my (former?) industry, and the way I see things.

First a quick job update, since I did interview for one of those support positions this week. I want to write code, not just answer angry customer questions, but they seem to have several internal candidates and they seem to want someone to just reproduce the issues and prove that a bug exists (see my earlier postings on that topic). A business consulting company gave me a quick phone screen, too, but I don't expect to hear back from them. Not because the phone screen went badly, but because I am competing against 100 other people, most of whom are younger than me and therefore more likely to stick around longer than I am (that is what I hear from some recruiters, at least).

I registered myself on eLance this week, a free-lancing contract website. I think there are at least 50,000 other registered members who do software contracting though. This speaks to one of the issues I wanted to write about. I think we are seeing the end of software and computer development in this country.

When I started out, the mini-computer was a big deal, and the personal computer was just about to become a big deal. Kids coming out of school for the next 25 years were targeting some form of computer or networking career. Today, these jobs are viewed as a commodity to be outsourced to the low bidder. The innovation that is happening in this country is mostly around better ways to shop online and tell your friends what you are shopping for, and where to find the next coupon. A lot of young people have Wall Street as their ideal job now.

I see this as closely related to what I have experienced on the job. Too many of my colleagues seem to believe that they know more than the customer. This leads to an "attitude of least effort". In this mindset, anything that takes more than a few minutes of work is deemed "too hard" and "not worth doing". If you get really good with this technique, your job becomes a series of status reports where you diss everything that is proposed as worthless and too expensive to pursue, and you don't need to actually work on anything other than your next status report. It usually helps if you also complain about how long it takes to write the status report.

The goal is to work on the newest technology and the most fun projects with the fewest requirements and no actual customers. That way you pick up new skills and never have to deal with real product development or support. I know this, because that was my goal early in my career too. If you do land in such a position, you get to speculate on what your possible customer base might want, because no one really knows, including the marketing people. You use all the latest techniques to teach yourself the newest framework or JDK release. You avoid virtually any schedule constraints (the schedule is made up by marketing people and is therefore meaningless). You get to put in features that you believe are critical, at least if you are good at yelling about how critical the feature will be. Usually there is a real sense of urgency though, because if you don't demonstrate a few cool features, your wonderful job goes away, project cancelled.

So I'll try to relate this back to some general industry observations. It seems to me that there are broadly three categories of software developers. These are the prototypers, the product developers, and the sustaining developers. Very rarely you find someone who can bridge two of these categories, and even more rarely, all three. The Prototyper is the person I just described, who follows the new technology and doesn't actually ever deal with customers, let alone with the second product release. In my experience, the Prototypers are the folks being hired at Google, Amazon and other places. They are very smart. They can answer all kinds of questions about design patterns and the latest sorting algorithms and the latest Java frameworks. They crank out vast amounts of code that implements flashy new features. They usually have little interest in building in any kind of extensibility or troubleshooting features, because that is boring and that is what the Product Developer is for. They advocate for Agile and believe that a large quantity of new features equates to a Product. It usually does, but always in Release 1.0 form. Product quality, which I define as the perception of the customer that the product is fun to use, reliable and intuitive, usually falls by the wayside. This is what happened with Google Buzz, in my opinion. It also happened with a couple of major product releases I was associated with at Cisco.


The focus on Agile methodology strikes me as a kind of last gasp attempt to keep software development in this country. It ties software development to rapid cycles that focus on the next feature. There is no thought of long term product and service support. It is the antithesis of the waterfall model that is at the core of the CMM and outsourcing successes. Where the CMM crew focuses on statistical measurement of quality (just about as bad a way as there is to measure success, in my opinion) the Agile crew focuses on the rate of new features. The common element is a lack of focus on the customer and the longer term services that can be built around a product.

Now the Agile crew will tell you that the Process allows you to rapidly fix customer problems. Throw the new feature or fix out there, and see what pain it causes, and then rapidly fix it. The problem is that the PROCESS doesn't write good software. That only comes from good management and good Product Developers. The Prototypers are already gone from the project, re-assigned to the newest thing. In its worst form, this mindset leads to a huge pile of hacks, with zero documentation. Sound familiar?

Okay, back to the three categories. The Product Developer usually cares about a solid job, a good manager, and the opportunity to somehow make a difference at the company. Usually the goal is to find a niche where you demonstrate a thorough understanding of the component or subsystem, and the way in which the customers are using it. You become an expert in a specific area, and you focus on making the product better for the customer, and easier for you and others to troubleshoot. After the third or fourth time that the technical support group asks you to diagnose a core dump, you tend to start thinking about ways to avoid the core dump, or at least make it simple for the field support people to diagnose the core dump. You find all those CASE statements with no DEFAULT case, and the IF-THEN constructs with no ELSE clause, and the empty CATCH blocks that the Prototyper didn't want to think about because it would slow down the innovative thinking process and cause the current scrum deadline to slip out. Besides, the Prototyper argued that "the probability of anyone causing that scenario is very very low. It will almost never happen and is not worth my highly paid brain cycles to think about any more." After the tenth customer complains that the data input method is awkward and caused them to enter invalid data, you tend to try to think of better ways to structure the product's work flow, so you won't have to keep answering this question by telling the customers that they are stupid for not reading the eighteen warnings in the user guide on how NOT to enter data into this product.

The third category is the Sustaining Developer. Most often these folks also have what I call a "contractor mentality" in the sense that they love to work on short term issues with a well defined purpose and time frame. There is no concern about corporate strategy or angry debates about which tool framework should be used next. There is only the bug list, the customer and the bug fix. There is closure to your day, nearly every day. You get to solve real problems for real customers, and sometimes you are even recognized or rewarded for this. Not often, but sometimes.

Okay, a long posting again, and no new emails or phone calls today. I need to ping a friend of a friend about a startup he is trying to get off the ground. Maybe its a good day to go XC skiing at the local golf course, too.

No comments:

Post a Comment