Two Things I Regret

Have you ever been in an interview and gotten some variation on the question "What do you regret most about your last position?" Everyone hates questions like that. They're a huge risk with little upside for you. You're caught between the Scylla of honesty and the Charybdis of revealing unflattering things about yourself.

Still, such questions can be very valuable if used personally for analysis and improvement. In that light, I'll share with you two things I regret about my stay at XanGo. Since I've ripped on the environment there in the past, it's only fair if I elaborate on things that were under my control at the time--things I could have done better.

Neglecting the User

Tim was the Senior IT Manager (the position that became IT Director once XanGo had grown up a bit). He was the best boss I ever had. His tech skills were top-notch (if somewhat "old school"). In addition, he knew his executives and how to communicate with them on a level they understood. It was a refreshing experience to have someone good at both technology and management (and since he's no longer my boss, you can take that to the bank :)).

After a little break-in time as the new Software Development Manager, Tim and I discussed what we needed to do for the organization. Tim's advice was to establish a pattern of delivering one new "toy" for our Distributors each month. He said that the executive board are very attached to the Distributors and that keeping things fresh and delivering new functionality and tools to them each month would make sure that we had enough of the right kind of visibility. Goodwill in the bank, so to speak.

This sounded like a great idea, and frankly, "toy" was loosely defined enough that it shouldn't have been a hard thing to do. It turned out to be a lot harder than expected, however. In my defense, I'll point out that we were experiencing between 15% and 20% growth per month and that we had done so since the company had started a year and a half before. That growth continued my entire tenure there. Now, if you've never experienced that kind of growth, let me point out some of what that means.

First off, using the Rule of 72 (the coolest numeric rule I know) will tell you that we were doubling every 4 to 5 months (in every significant measure--sales, revenue, Distributors, traffic, shipping, everything).

In case you've never experienced that kind of growth, it feels like ice-skating with a jet engine fired up on your back. Even good architecture will strain with that kind of relentless growth. When this happens, you become hyper-vigilant for signs of strain. This vigilance has sufficient reality to be important to maintain. Unfortunately, it also makes it easy to forget your users.

Developers like to live in a pristine world of logic and procedure. Unfortunately, life, and users, aren't like that. If they were, there'd be less need for developers. Users don't see all the bullets you dodged. They take for granted the fact that a system originally designed for a small start up is now pulling off enterprise-level stunts. They don't see it, so it doesn't exist. It is very easy to get caught up in the technology and forget that often it is the little touches that make your product meaningful. Sometimes the new report you spent an hour hacking together means more than the three weeks of sweating out communication with a new bank transaction processor. And by means more, I mean "is more valuable than".

Not that you can afford to neglect your architecture or needed improvements to sustain the needs of the company and prepare for foreseeable events. If you ignore that little glitch in the payments processing this month, you have really no excuse when it decides to spew chunks spectacularly next month.

What I'm saying here is that you have to balance functionality with perceived value. You have to know your users and their expectations because if you aren't meeting those expectations, no amount of technical expertise or developer-fu is going to help you when things get rough. In the case of XanGo, I could have afforded to ease up on the architecture enough to kick out monthly toys for the users. Yeah, some things would have been a touch rockier, but looking back there was room for a better balance.

Premature Deprecation

When I arrived at XanGo, our original product (a customized vertical market app written in VB6 on MS SQL Server) was serving way beyond its original specifications. We'd made some customizations, many of them penetrating deep into the core of the product. Our primary concern, however, was the Internet application used by our Distributors in managing their sales. We spent a month or two moving it from ASP to ASP.NET and ironing out bugs brought on by the number of concurrent users we had to maintain. We also removed the dependence on a couple of VB6 modules that were spitting out raw HTML (yeah, I know. All I can say is that I didn't design the monster).

Anyway, after that was well enough in hand, we gave a serious look to that VB6 vertical market app. Since VB6 wasn't all that hot at concurrent data access and couldn't handle some of the functionality we were delivering over the new web app, we decided that it should be phased out. Adding to this decision was the fact that we had lost control of the customizations to that app and what we had wouldn't compile in its present state.

Now developers (and for any management-fu I may have acquired, I remain a developer at heart) tend to be optimistic souls, so we figured "no big", we'll be replacing this app anyway. And we set to work. Bad choice. In a high growth environment, the inability to fix bugs now takes on a magnified importance. Replacing an application always takes longer than you expect if only because it's so easy to take the current functionality for granted. Any replacement has to be at least as good as the current application, and should preferably provide significant, visible improvements.

The result of this decision was that we limped along for quite some time before we finally came to the conclusion that we absolutely must have the ability to fix the current app. We paid a lot of political capital for that lack. In the end, it took a top developer out of circulation for a while but once it was done, it was astonishing how much pressure was lifted from Development.

It's the Users, Stupid

No, I did not mean to say "It's the stupid users." When it comes right down to it, software exists to serve users, not the other way around. As developers, it is easy to acquire a casual (or even vehement) dislike of our users. They are never satisfied, they do crazy stuff that makes no sense, and they're always asking for more. It's tempting to think that things would be so much better without them.*

I got into computers because I like making computers do cool stuff. Whatever gets developers into computers, though, it's a good idea to poke your head up periodically and see what your users are doing. Get to know who they are. Find out what they think about what you've provided for them. Losing that focus can cost you. Sometimes dearly.

*I think one of the draws of Open Source is that the developer is the user. It's also the primary drawback. But that's a post for another day.

 

17. November 2006 20:10 by Jacob | Comments (0) | Permalink

Lying Liars

It has become something of a tradition in IT circles, particularly in Software Development, to trash your predecessor. There are a number of perfectly valid reasons to do so, of course. The old guy isn't there any more and he took with him a good chunk of institutional knowledge that is now lost--things like what were they thinking when they did that. And you want to look good to your new boss, the simplest way being to trash the guy who left him in the lurch by leaving or who got himself fired for (presumably) plenty sufficient reason.

Knowing the tradition well, having been to my shame a participant from time to time, I expected to hear stuff when I was given "involuntary sabbatical" from XanGo recently. Well, my expectations have been exceeded, it seems, and I find myself in the most extraordinary position. How do you defend your track-record against public assault when you have signed an agreement not to disclose proprietary business information about your former employer? Even saying "there was no such project!" is enough to constitute a potential violation. New IT management at XanGo has decided to spend a whopping lot of cash to bring in a new tool that will rid them of all cares and worries, bring paradise on Earth, and cut current and future costs practically to zero all at the same time. This new vendor has made it a practice of leveraging the contract with XanGo by making the most outrageous claims about former XanGo development practices and how purchasing the new tool has solved all their problems.

Since I still have friends in XanGo IT, I have had a front-row seat to the goings on since my departure. It has been frustrating for me to watch as the pain begins to penetrate there. This new tool has some serious "feature challenges" that have plagued the poor souls left to attempt implementing them. No source control, no Unicode support, seriously compromised object oriented principles, clumsy system backup, you get the picture. It's a nightmare for any serious developer to work with, particularly in a multi-developer environment. And worse still because they have been forbidden from speaking of any of the drawbacks or challenges with threats of being fired should they squawk even internally at XanGo. And since the project seems so doomed, when it comes time to implement this great new tool, they are pretty clear that the sacrifices to expedience will be the developers due to their "lack of performance" (because such a great tool must mean that they are the reason for failure).

So I'm being trashed, the team I left behind has been cut all to pieces and some of the best programmers I know are finding their competence being denigrated all for the sake of a questionable business relationship of questionable value to the company with a partner who was very near closing their doors until the XanGo contract showed up and saved them from worry or care (how looking at the financials and law suits against the company didn't prevent them from going with this vendor I'll never know).

How do things like this happen? How does a rapidly growing company leave itself open to such outrageous conduct, and what can possibly be done about it? I don't have any answers to those questions. Frankly, there isn't a lot that can be done from where I sit. The only ones with the power to alter the situation are busy with all the concerns brought about by their rapid growth and popularity. Anything I can do is compromised by the fact that I was forced out in the first place, anything I say is easily dismissed as mere bitterness and spite.

I will say this, though: This whole thing has strengthened my resolve not to participate in the time-honored tradition of trash-the-old-guy in my next position. And it has strengthened my suspicion of tool vendors and their extravagant claims of cost/time savings.

Technorati Tags: ,
8. June 2005 10:41 by Jacob | Comments (0) | Permalink

Calendar

<<  February 2017  >>
MoTuWeThFrSaSu
303112345
6789101112
13141516171819
20212223242526
272812345
6789101112

View posts in large calendar