Random Traffic Through Nick's Brain

bullet point stream of consciousness may occur at times…

My first major project at work hit production while I was on vacation. It wasn’t the disaster that I had nightmares about. Thankfully.

Project management instills me with a feeling of helplessness. You depend on other people. Not everyone is a Smooth or a Sheffi. How do you estimate how long it will take someone who is more junior / less skilled than you are to do something? Relying on their estimate isn’t always right, because, heck, their estimation skills may not be their forté.

I have the urge to code, even if I should be overseeing things. I broke down and coded something that I should have delegated. Is this bad?

I’m done. It didn’t blow up. It is useful. But… will it be used?

On this project, I was worried that my architecture wouldn’t be up to snuff. I was worried that I wouldn’t be able to do it well enough. My new project is more familiar. I’m simply not sure if I’ll be able to get it done on time. Much more reassuring… I know how to deal with that.

Honest introspection and the outward appearance of self-confidence are two things that I have yet to reconcile.

Programming People entries will examining managerial and motivational type topics. Most of the time it will be related to work, but sometimes it deals with social dynamics. This may belong in Thoughts On Development, but it’s of interest to non-developers also.

The name of the topic comes from HB. One way to think of managing people is to think of it as “programming people”, just as one would program computers. You have a goal you wish to accomplish. It can involve convincing a computer to perform tasks using software. Apparently, it can involve convincing a person to perform tasks (involving a computer to perform tasks using software) using wetware. That description appeals to me enough that I’m interested in at least trying it. I disagree somewhat with my CIO’s thought that if you can apply brain power to a software problem then you apply the same brain power to wetware problems. I think that certain patterns of thought work well when manipulating computers. Others work well when manipulating people. If my skills at manipulating people were as good as my skills at manipulating computers, I would have gone into a different field. On the other hand, maybe my skills at manipulating people aren’t good because I don’t have as much interest in doing it.

Of course, I’m going to have to self-censor here for a couple of reasons. First, I don’t want to provide too many details about work. That shouldn’t be too hard. Second, some of the techniques used in social dynamic situations don’t necessarily work if people are aware of them. In fact, the last sentence may be enough to heisenberg some situations.

Anyway, enough of the intro, on to some situations.

Some of the new responsibilities that I’m stepping into are resource allocation and scheduling. Motivating developers to do things is also proving problematic. Though our general office culture of “focus on what is in front of you at the expense of tomorrow” may be getting in my way, the problem is squarely on my shoulders. There are a couple of things of interest for now.

First, how do you estimate how long it will take someone else to do things? I’ve become quite adept at estimating how long it will take me to do something. I’ve also learned to handle surrounding issues, such as pitching inflated numbers to managers to provide space for the inevitable emergency they will throw at me, and then discount when it comes to figuring out if I hit my targets. I’ve also learned to lowball estimates when convenient. Mostly when I know some other developer has also lowballed, either intentionally, or because, like most developers, they can’t estimate for shit. Sometimes lowballing is important when something absolutely needs to get done but managers won’t be happy with the fully loaded time estimate. Lowball. Partially implement. Display benefits to managers. Managers give you more time.

But I digress. How do you estimate how long it will take another to do something? Well, the first question is, do you know who that someone is? If so, HB suggests that I ask that person how long they think it will take to implement. Besides getting an estimate from the person who is most familiar with their work, there is also an element of buy-in. Instead of some Pointy Haired Boss handing them a schedule, they are participating. They have motivation to hit the deadline that they suggest. It has the downside of relying on a developer’s estimation skills, which may well suck. I’m awaiting wisdom on this one from someone with more experience from work.

Second, how do you get someone to do something you ask them to? I’ve asked someone to perform specific tasks in order to prepare for some work we have to do. Repeatedly. The task is well within the abilities of the person asked to perform it. Dan suggests sitting down with them and walking them through the task. That seems particularly wasteful of my time, and limited supply of patience. As I write this, I’m starting to fret more and more about my deadlines.

On a related topic, how do you teach developers how to automate tasks, making both their jobs, and the jobs of those around them easier. Talking to HB about this, he suggests the best way to program developers is to demonstrate success to them. This involves:

1. Saying what you are going to automate.
2. Saying what you expect to happen from automating it.
3. Giving them the task of actually automating it.
4. Giving them the task of evaluating the results.

Roughly, explain the benefits, tell them to do what you want, tell them to observe the benefits. Once they have done this once, you can ask them to make suggestions about other things to automate. Once they’ve lived it for one cycle, they’ll have a much better appreciation of the trade-offs between time to develop, time saved, and time wasted because of automation bugs.

On a meta level, HB is teaching me “How to teach developers: ‘How to automate.’”. Thank you HB.

Received in IM from a coworker (abridged):

Coworker: There's something beautiful about the caching code as
          we've implemented it. And I don't say that about a
          lot of the code here.
Me:       Why do you now find it beautiful?
Coworker: Ummm... It seems simple, understandable, flexible.

Now, I’m no slouch when it comes to OO design, but I’ve always felt a bit behind most of my friends who are in the same line of work that I am. I was very surprised at how good the compliment made me feel.

Now we just have to see if the implementation and performance match the design.

I finally bought a Pocket Book that fits in my back pocket. Ah ha!

I’ve come to understand the difference between the “professional” and “enterprise” version of software. In one tool we bought, the professional version is perfect for, well, a professional developer to run against his code. The enterprise version is automatable, suitable for running against an automated build.

Speaking of which, build automation is pretty cool.

Yesterday was one of the most productive days I’ve had in a long time. Finally got FxCop (static assembly analysis), NUnit (unit testing framework), NDoc (help file generation) up, running, and automated on test projects. I’m really impressed with NDoc. Generates compiled help and web pages that look like the MSDN documentation from your XML comments. Of course, it’s easy to automate with NAnt already running. Next, I have to look at Log4Net (logging framework), NUnitASP (ASPX unit testing), and Draco.Net (continuous integration). It should be relatively easy to get the up and running at work. The hard part, of course, will be to get other people to use the tools.

My VS.Net macro suite is also growing at a fair clip, both my own macros, and stuff grabbed off the web. I think I’m going to start posting some of them here in an attempt to get more regular updates to the Thoughts on Development section.

Intro

I’ve been at my new job for 3.5 months now. First, that means that I’ve passed my probationary period. More importantly, it means that my brain is now getting more and more into the habit of thinking. I’m starting to want to read more, both technical, and non-technical, fiction and non-fiction. It also means that I’m getting more and more epiphanies. A lot of things are coming together.

Problem Solving Is Not Solving The Problem For Me

One thing that still hasn’t come together for me is problem solving in a work environment. In a home environment, once you solve a problem, it’ll normally stay fixed. You don’t have to pay much attention to it.

At work, I’m getting paid to solve problems. See… that’s an example of how deep me not groking this idea really is. I’m not really getting paid to solve problems. Solving problems is the thing that I do the most of at work, and on the surface, it looks like that’s what I get paid for.

It’s not.

I get paid to know how to solve the problem, and to keep the problem from happening.

It’s not useful if I twiddle with configurations if I can’t figure out which twiddle solved the problem. I have to be able to extend my problem solving skills to the relevant portions of my organization.

Though a fairly simple concept, it, as many simple concepts do, has a lot of ramifications.

• I should be documenting things that I am doing, so that others in the organization can benefit.
• The way I wrap my message is important. It doesn’t matter if I know something if I can’t flow that information to the rest of the organization in a manner that will make them listen.
• It is not enough for me to architect something such that it helps me solve problems. The architecture, as well as my code, needs to have a competitive edge over the lazy way of doing things. The solution to the problem has to be seductive.
• …

Cost Gradient

One of the things about good development practice and architecture is that you want to break things. OK… what you really want to do is break things sooner. A bug is an order of magnitude more costly each milestone (project accepted, design, development, test, prod) it passes. What a good software engineer wants to do is push the bug down the cost gradient. Unfortunately, this is generally up the effort gradient. That’s why humans, being naturally lazy, aren’t always good at this. Short term, planning for the long term is hard.

One of the things that I’ve come to worry about at work is perception. When you expose bugs sooner, even if they are other people’s bugse.g. You just put logging statements in the code to show something bad is happening people have a tendency to blame the messenger. Uncovering bugs in production that no one knew about, but affect thousands of our users would seem like a good thing. It is. But if you don’t do it correctly, people will think that you are responsible for the thousands of bugs.

I think that one of the things that I like about my job is that, although the responsibility for dealing with the bug may fall to the messenger, they don’t really seem to be blaming the messenger.

Panopticon

I’ve been an avid reader of software engineering best practice type books, covering everything from deep in the code books, specialized / niche technology tomes, social dynamics, design, psychology, etc. It’s starting to come together. A lot of the ideas that I understood, I am slowly starting to grok. I’m at the point where ideas are forming on their own. Kinda scary.

I think that there are a number of reasons for this. The heavy volume of reading was a good foundation. Accumulating experience never hurts. My brain getting into gear no doubt helps.

I think the most important factor, though, is the fact that I’ve now ‘worked’ at three very different companies in the last year. The ability to compare and contrast, and to see that solutions have to be tailored to the company has brought a lot of issues into focus.

Was in one of the comic stores in Harvard Square today. A middle aged couple was discussing anti-Bush / anti-Right / left t-shirts, bumper stickers, and web sites. It was nice to be able to point them to Patriot Savant, run by a friend of mine. Felt almost as good as voting.

I emailed a couple of friends asking them for Linux distro suggestions. I think that WindowsXP Pro pulled a jealous tantrum. It blue-screened on reboot. Even safe mode wouldn’t work. I finally figured out how to use the recovery console to do a chkdsk on it. I feel sorry for the non-techie who has to figure out how to do something like that. Someone like my mom might just buy a new computer, or abandon them forever. Now I just have to figure out whether it was installing remote admin software, or something caused by a power flap.

Maybe this belongs in thoughts on development, maybe not.

A week or so back, we were driving to lunch, and discussing some architectural or process short coming in our current system. One of my younger co-workers, with only 3 or so years experience said something like “Obviously, it should be done like this.”

That statement made me realize what a great education working at ITG was. I learned zoots about all the non-coding issues that surround software development. Now that I’m at a new job, I realize how much I’ve learned over the past five years. I also realize that I still have a lot to learn… mainly when it comes to putting what I know into practice.

The more I learn about software development, the more I realize that my paycheque is a bribe to write sub-optimal software.

Not much of note going on lately other than work. I’m learning a lot about .NET and ASP.NET as I port ASP code. Hopefully, I’ll have some entries for thoughts on development soon.

src=”/pictures/maritime-road-trip/maritime-road-trip-nh-lake-2003-05_small.jpg”
class=”alignright”
style=”width : 150px; height : 97px;”
alt=”Photograph: New Hampshire Lake, 2003-04, © Nick Varacalli.”
title=”New Hampshire Lake, 2003-04, © Nick Varacalli.”
/>
I’m coming to realize that I have problems understanding the underlying concepts of situations.
This comes into play a lot when I have to understand the problem domain for something I am programming.
In some ways, it is frustrating that I learn the domain that slowly or shallowly.
At least there is an upside to this.
I can implement solutions with minimal knowledge of the underlying domain.

This might be construed as thoughts about software development. On the other hand, this applies in a much broader context to life, so it’s here.

There is a thought in software engineering that things should be done “The Right Way ™”. Take the extra little bit of time (and therefore money) to write software correctly the first time. In the end, this saves money because industry studies have shown that avoiding a bug by coding correctly is cheap compared to the other options. If the bug is found in testing, before the software is released to customers (whether shrink wrap, or internal) it is about 10 times as costly to fix and re-test. If the bug is found in production, after the software is released to customers, it is about 100 times as costly to fix, re-test, and re-deploy. This ignores the loss of trust by the users of your software.

Assuming that the figures above are right, are there times when it is appropriate to do things “Not The Right Way ™”? I’m starting to think that the answer is, unfortunately, yes.

One of the problems with doing things right is that it the cost is incurred up front. Shortsighted people, wanting to avoid costs, and not being astute enough to see the costs downstream, therefore prefer that things not get done the right way. Trying to convince these people of doing things right burns office-politics karma. You may be pigeonholed as difficult to work with, nitpicky, perfectionists, and all sorts of things that you would think are compliments, but really aren’t in a corporate environment.

“Ah,” you say, “all we have to do is to show them the costs downstream.”

It’s not that easy. If you work for an organization where shortsightedness is endemic and learning from experience doesn’t happen, it is near impossible to convince people of the usefulness of doing things now that pay off later. A good example is our ex-department, ITG, in the context of Merrill Lynch. Most of us were hired because, among other qualities, we had a passion about doing things “The Right Way ™”. It was one of the things that caused a lot of us individually, and our department, to be painted with a difficult-to-work-with brush.

The problem is that in a shortsighted environment, no one remembers that things are easier now because you did the right thing yesterday, last week, last month, or last year. It would have been just as easy now even if you hadn’t done it the right way. No one can correlate the fact that things are hard now with the fact that you didn’t do it the right way in the past. Attempting to point out that you are in a pickle because of poor decisions in the past simply gets you label you as a wise-ass, I-told-you-so type person. All people will remember is that you wasted time and money trying to get things done your way. You’re being stubborn and unresponsive.

Yes, I realize that the definition doing things right is highly subjective. There are times, however, when it is apparent that approaches to problem solving have not been thought out.

I think that one thing that my new job is teaching me is that I can’t be as passionate about optimizing for efficiency, and doing things right when others are involved. I’m now a consultant. The customer is always right. I can suggest what I think is the correct way of doing things. The customer is free to ignore said advice. I will attempt not to say I told you so, no matter the guise.

However, I’m still looking for a job that will let me be passionate about it again…

On a personal level, I guess this means that I can’t get frustrated when I optimize for something in a situation, and then things don’t go the way I planned due to outside factors.

On the other hand, maybe what this means is that I have to learn to be (much) more persuasive in convincing others of the righteousness of my convictions. Hmmm… fat chance of that. I’m not that persuasive, I’m probably not that right, and you can lead a horse to water…