Embracing pain

Back in the 80’s there was an exercise slogan “no pain, no gain”. The original concept was simply to work-out with an intensity and duration so you began to feel discomfort. If you weren’t experiencing some discomfort during your work-out you probably weren’t pushing yourself enough to result in growth and progress. The marketing campaign was eventually abandoned, because too many people were misinterpreting the message, and were simply injuring themselves during a workout, and often had to abandon their workouts altogether.

In the software development and IT (generally), there are different kinds of pain too. Some of them are bad and you want to avoid them: blowing a deadline, crashing a prod server, security breech …those are bad.

In contrast, there are other types of pain, which show that you are pushing the envelope and growing.

  • Blowing a checkpoint early in a project, and then making adjustments/corrections to get things back on-track
  • Crashing a test or pre-prod server instead of a prod server
  • Struggling to get a prototype to work correctly
  • Abandoning a bad design
  • Refactoring part of a project
  • Finding a “show stopper” bug in QA or Pre-Prod

Each of these are the right kinds of mistakes to make. Some of these show that your test/QA/pre-prod environments are providing a good value, or that you are taking some risks, or cutting losses in a way that will protect the majority of your project.

Even if you do experience the bad kind of pain, there are still benefits to gain: They say you can learn more from your mistakes than from your successes. Of course, if you dodge the responsibility or outright deny that there is/was a problem, then you will probably learn nothing. But if you address the problem, discover the root-causes and take steps to prevent similar problems the future, then you have probably gained some real ROI from something bad.

It comes down to attitude. Don’t avoid the discomfort that goes-along-with exerting yourself. Push yourself a little harder. Encourage that growth. Earn your muscles.

Advertisements
Posted in Lessons Learned | Tagged , , , , | Leave a comment

Why communication is hard, and what to do about it

I know IT folks sometimes seem under-socialized and (to varying degrees) awkward. However, they don’t have the market-cornered on communication problems. Gosh, just turn on any TV sitcom and you will probably see a people who are having conflicts because they are miscommunicating and misunderstanding each-other. I even recall feuds between family members because “she said this to her, which was totally out-of-line”, but later they apologized because it was all just a big misunderstanding. Right? You’ve never seen that before, have you? LOL. Maybe every-day, right?

IT folks are very much like everyone else, on the inside. Any person’s primary motivation for communicating is to benefit themselves. Even if they are doing it to help others, the primary motivation is to advance their own initiative or current task. Teamwork is good too, but I like my team better than any other team. You get the pattern. It is human nature.

So when things go wrong with communications, the problem usually stems from two things.

  1. People tend to think about themselves. When you are communicating with someone else, that person is trying to think about what they need or how you are going to help them. If your side of the conversation is strictly geared towards helping yourself, the other person might have trouble relating-to what you are trying to communicate. Sometimes this can become quite baffling for folks. Like if I say I want a burger and your response is “I want a taco”, I might think, “I don’t want a taco. Why is he talking about tacos? WTH”
  2. People tend to expect from others, what they expect from themselves. On one occasion, I recall dealing with a person who was convinced that I was trying to subvert him in some way. Which is completely against my nature. I just don’t operate like that, and I was astounded that the other person would even suspect that I could be capable of such guile. It took me a while to remember this point: the other person probably had a subversive nature and was simply expecting me to act the same. It was astounding (to that person) to think that I could be genuinely offering to help without some spectacular agenda for myself. After that exchange I was very careful about how I interacted with that person. VERY careful.

In the end, it comes down to empathy. If you spend your time thinking about yourself, then you will have trouble motivating others. Once you have empathy, and understand what motivates others, you can begin to work on agendas that will benefit both of you.

Of course, to have empathy means you need to understand others. It only works if you know what makes other people tick. So, you need to start by getting to know others. You probably need to ask questions and listen to the answers. Think about what the other person said, and why. Eventually, you may need to read a little more about what makes others tick. Mostly, because not-everyone is wired the same and therefore is not motivated by the same things.

Most people really do want to be understood and are glad to work with you. If not, you will notice when a person’s actions and words don’t line up. That is a discussion for another time.

Posted in IT Psychology, Professionalism, Team | Tagged , , | Leave a comment

Why bother with a plan

I have met plenty of cowboys in my day. I’ve written about this topic several times. One thing that cowboys hate, is writing-up a plan. It makes me think of the times when I MAKE my kids do homework. Their effort to avoid doing homework, usually is greater than the homework itself.

It probably isn’t a surprise that I’ve also worked with people who were not cowboys, but still refused to write-down their plans. Maybe you are you familiar with the saying “failing to plan is planning to fail”. It is a catchy saying, but how accurate could it be? After all, if it was true, a cowboy would always fail. Right? However, cowboys don’t seem to constantly fail. Perhaps this is iron-clad evidence which contradicts this catchy slogan.

To plan, or not to plan

So-many people do-not believe in plans because they have operated without a plan and have experienced varying degrees of success. Therefore, to them, a plan is just some BS busy-work that has low ROI. I’ve heard the same about Algebra homework. (deep sigh, and eye-roll).

Well, good news/bad news: This negative rhetoric may be accurate under some circumstances, but I cannot name very-many times where [having a plan] was actually a complete waste of time. So, let’s start with some conditions where [having a plan] will probably end-up being a total waste of time.

  • Very small tasks
  • Busy-work
  • Tasks where creativity is the fundamental goal
  • Tasks which only involve one, maybe two people
  • Tasks where the outcome is unclear and it is impractical to plan “research” or “discovery”
  • Tasks which require a cowboy (emergency outage in production, or a panicked fix)

In contrast, I guess you could say, nearly every other condition is a time when you want to have a plan. For example:

  • Large projects (or even medium projects), which require coordination and timing
  • Projects which are being watched by important people
  • Projects with a significant budget and expected ROI
  • Projects which should be predictable
  • Tasks which require surgical precision and zero margin for error

For work like this, there really is no excuse for not having a plan. If you’ve done something before, you know what you are doing, you can predict how things will go, then make a plan to show that you really do know what you are doing. As you hit your marks, it will increase confidence in your process and skills. Clearly you must know what you are doing if this is so predictable, and you predicted it so well.

Of course, there will always be some surprises on any project, so document your expectations about those too. If you encounter more surprises than you anticipated, then adjust your plan and adjust your work to bring the project back to the plan. It might sound inconceivable to predict surprises, but with some experience, you will come to expect surprises and you will prepare to 1) recognize them early, and 2) react to them and handle them so they don’t derail your plan or timeline.

Bottom line, if you know what you are doing AND you are not a cowboy, then cowboy-up: write-down your sweet plan and sport it like the magnificent elitist that you and I know you are.

Posted in Lessons Learned, Professionalism | Tagged , , , | Leave a comment

Getting through to someone

Today was like a whole new day for me. I got through to someone. Maybe it doesn’t sound like a big deal to you, but I have teenage kids. So, I don’t exactly feel like “I’m getting through” to people each day, y’know.

So, here is what lead up to this: Our dev processes is pretty good, but there are still opportunities for improvement. Last week, things didn’t go so well. So in our weekly meeting, we wanted to talk about it and see what we can do better. Here is an excerpt.

  • Dissatisfied client: Your team did this thing and it caused me a bunch of additional work. I wish that had not happened.
  • Defensive teammate: No, let me explain. It wasn’t my fault because something, something, blah blah blah. (long-winded explanation)
  • Dissatisfied client: I wish you had informed me of this problem, because it would have saved me a bunch of time, researching the root cause of the problem, on my own.
  • Defensive teammate: Let me explain. (goes over the same explanation, but with a few minor details added)
  • Dissatisfied client: Well that is nice but still
  • Defensive teammate: (still trying to explain why it is not his fault)
  • Team lead: (interrupts both of them) (to client) I understand what you are saying. This was an honest mistake on our part and you are right. We should have kept you informed. Next time we will take steps to prevent the mistake from happening, but if it happens anyway, we will let you know what is going on, so you don’t have to wonder.
  • Dissatisfied (but improving) client: Okay. Thank you.

Let’s just say, I’ve seen something like this before, and not just from one person in my career. (ehem, looks in mirror). If you work with technical people, please be aware that, when something goes wrong, they LOVE hearing the story about “why” and “how”. To them, it is like a Readers Digest mystery. Mentally tantalizing, and briefly entertaining, but much more enjoyable if it didn’t happen to you.

Unfortunately, non-technical people h-a-t-e this sort of thing.

It reminds me of people from New York. If you know anyone from New York, they are notorious for having a complete lack of patience. They have some imagined notion that they are losing money for every word that they hear. If you are speaking, you are taking money out of their pockets. They might chagrin, or give cues that they are getting impatient. Eventually they snap and say “is there a point to your story?!” (abruptly like that!) If it ever happens twice, you will surely get an earful. It is your reward for being cordial and chit-chatting with them. Mee-ow! In New York I guess, “pay-shins is fuh doctuzz”.

Anyway, non-technical people feel the same way about technical people sometimes. They don’t want the back-story. They just want to know that it won’t happen again. Maybe they want to hear about how you will ensure that “this will never happen again”, or maybe not. Look for clues in body-language. (chagrin, gestures, eye rolling, or a “glazed-over” look)

Good luck telling that to a technical person. …. 0.0

Yeah. That technical-person will be stunned by your abruptness. He probably believes it would be incredibly rude (on his part) to solve a problem and NOT explain it to others. It sounds too selfish and uncooperative. Certainly, we don’t want technical people with those kinds of manners on our team. Now do we?!

So, with my colleague, I had to find some good words to reach him:

  • Me: The client said they didn’t like what happened and you started arguing.
  • Defensive teammate: I was just trying to explain … (goes over the entire explanation for me, again)
  • Me: How did the customer like your response?
  • Defensive teammate: I don’t know. I guess they kept asking for a better explanation.
  • Me: are you sure about that? Because your team lead seemed to give a different response, and the client seemed more-satisfied by that.
  • Defensive teammate: I don’t recall that. But I do recall the team lead interrupting me.
  • Me: Did the customer seem more-satisfied by her answer?
  • Defensive teammate: I don’t know (and starts explaining the ENTIRE story AGAIN)
  • Me: (interrupts). Hold on. Is it possible that the customer wanted a different answer, and once he got it, he stopped asking for a different answer?
  • Defensive teammate: (attempts to explain the goshdarn story, yet again)
  • Me: (interrupts again) Your answer was valid and I liked the answer, but the client was looking for a different answer. Your teammate interrupted, to give the answer that the client wanted. This resolved everything and we moved-on.
  • Teammate: (stops to think for a minute). Then attempts to explain the situation differently to me, AGAIN.

At that point, the irony of the situation hit me and I started laughing. My perplexed teammate stopped for a moment.

I explained that this was very ironic. He was simply repeating the same pattern with me now, and giving me an answer that I didn’t want. “Can you see that I just asked you (a few times), because I wanted a different answer? Basically, what I really wanted was reassurance that this wouldn’t keep happening over-and-over again.”

He was silent for a moment and displayed an expression of deep-thinking. I let him think about it for a minute or two. He relented that sometimes, you need to change your approach, to deal with different kinds of people. We agreed that there are times when we should look-for cues from people, which could indicate that we are not interacting-with-them in an optimal manner. Changing our approach can change the entire dynamic. You just have to look for those cues, so you know when to change your approach.

I must confess that it made my day. I knew it would be a lot of work, to get through to someone, but it is totally worth it when it actually works. I’ll try not to let it go to my head. 

Be patient my friends, and be ready to change your approach periodically. You might reach someone.

Posted in IT Psychology, Lessons Learned, Professionalism | Tagged , , | Leave a comment

Switching from dev-process to maint-process

I was going to name this article “Maturity model for maintenance programming”, but every time I read that title, I cringed. Maintenance programming is not much fun. It sounds a bit like “prison guard” or “mortician”, or some other unpleasant profession.

It is a tough job, but someone has to do it. More than that, the job needs to be done well. Imagine the results from a prison guard or mortician who is a slacker. You know the results would be unpleasant and people would be pretty unhappy with you. It is serious work and therefore, it needs to be done by someone with “guts”. If you have the guts to do it, then let me offer you my thanks in advance.

When you take-over a project from someone else (another person, or another team), there is a bunch of work to do. You will quickly find how the project went. It probably went like this: At first, your predecessors meant well. They started with some great plans and expectations. Everybody was optimistic and striving for perfection. As the project progressed, the roadblocks got bigger and the team eventually became weary. The closer the project got to the end of the timeline, the more all-of-that-talk about “the right way” tended to fall apart as the project got squeezed by a timeline, a budget and the remaining feature-set (and bugs). Something had to give. People made compromises and got things done. It was good-enough. Now that the project has been handed over to you, your job will be to find all of the sub-par stuff and create a scope-of-work to fix it.

The good news is that, once it is handed to you, the focus on timeline seems to go-away and the focus turns to “reliability”. Which really means [fix the bugs immediately]. Of course, what they really want is a bug-free system, but the term is misleading, because your predecessors will claim that they delivered a bug-free system and there is not much to do.

Removing “the suck”

There are several layers of improvement/maturity that you can take the project through. Each tier makes the system easier to maintain. However, each one also takes increasing discipline, planning, skill and effort to get the system to progress to the next level.

Here are the levels of maturity:

  1. Released – The project runs and has cleared testing. Hurray! Ship it!
    At this point, there are no expectations about maintainability. Up-to-now, the goal has (most likely) been to complete the project by a certain date, with a list of features-completed and passing some reasonable level of testing. If the authors were not required to maintain the code, there would have been no incentives for making the system maintainable.
  2. Customer Assessment – There are way-more customers than there were testers. The customers (end-users) are going to be more creative than your testers. They are a million monkeys sitting at keyboards and they will give you some Shakespeare eventually. And by “Shakespeare”, I mean “bugs that you never would have dreamt-of”. When those bugs arrive they will be waves crashing on your embankment and your level of resourcefulness will be the key to resolving the problems quickly.
  3. Stabilizing – The bug waves typically come in a pattern: 2-2-2-6. 2 days till the first wave, then 2 weeks later, then 2 months later, and it mostly subsides in 6 months. You will need to deploy your fixes between these waves of complaints. As you stabilize the app, you would expect the intensity of the complaints would gradually reduce. However, that doesn’t seem to actually happen. The complaints just become less frequent, after a while.
  4. Supportability – After 2 months, you will start to think about how much time (too much) you are spending on monitoring your app, or wading through code or data, to find problems. At this point, you will start to think of utilities or features in your program, which would make it easier to support. These productivity tools will give a fairly nice ROI. They will make your support-efforts move quicker and more-decisively.
  5. Performance – After you have several waves of bug fixes and updates, eventually some joker is going to complain that your site is slow. It wasn’t this slow in test (because you didn’t have any data). At this point, you need to do a performance study and optimize the app and database. Expect another of these in 18 months.
  6. Feature enhancement – After the bugs are (mostly) resolved, people will start chattering about how some of the features are not as good as they’d hoped, or it would be better if… So, there will be enhancements. This means new development. Which means you will have to switch gears back to requirement gathering and scope containment. How soon can the users get this new stuff? No, that is too long. Get it done sooner!

Not every project goes this smoothly or follows this timeline. This is the path a project is supposed to take. Of course there are some variances, based on project size, team size, budget, etc. However, if your project does not climb these levels, it is usually because your leaders are not aware of the natural progression.

It helps to know what to expect, so you can measure yourself against reasonable expectations. Also, if someone has unreasonable expectations, it is nice to have a nice/effective way of suggesting something more reasonable.

So plan your lifecycles, set expectations and stay l33t.

Posted in Lessons Learned, Methodology | Tagged , , | Leave a comment

How to get people to follow a process

Years ago, I worked on a team who was making an online trivia game. The concept was a very brilliant solution to a common problem. The customer was a huge company who processed credit applications for car purchases. Their financial services mgt had come up with a new initiative to boost sales. They were having problems convincing “the old-dogs” to try it. They were like “look, I don’t need this gimmick. I’ve been doing this for [x] years. I already know what I’m doing. Just leave me alone so I can do my job”. Management was frustrated with the uncooperative attitudes of some of these people, who were unaware that they were getting rusty.

The solution was a trivia game. It was designed to confirm that (at-least) each person had absorbed the training and the new concepts. Each week, new questions were posted and people gained points from correct answers. It tapped-into the competitive nature of people and motivated the staff to learn the materials, just so they could win the game. It was quite irresistible and it was a big success.

I wish this strategy could be applied to every problem, which involves stubborn people. Unfortunately, it is probably not strong enough. For instance, imagine if you were to come up with a new software development process, or documentation regimen for your staff. Ugh. Documentation. I’d rather eat liver, or brussel sprouts. How could you possibly get people to get on-board that wagon? I don’t think a competitive game amongst co-workers would be quite enough.

The solution lies in the end-game. Same as the trivia game, previously mentioned, the end-game is to win at whatever you are doing. The reason people hate documentation is because a developer will spend a bunch of time on it and nobody will ever read it or get any ROI from it. At least, that is the perception. Likewise, what is it about this new-fangled software dev process that makes it so superior to our old one? I have to break all of my habits (arguably good ones) to form new habits. I won’t drink the cool-aid unless I’m certain it will be much better-tasting.

As a leader, these are your points-of-focus:

  1. Help the team see and understand the problems that you are trying to solve
  2. Help them understand why the problems are bad
  3. Keep statistics for the side-effects of those problems
  4. Point-out that the current process gets you a “B-“, but you really want an “A”.
  5. Explain how the new process is designed to address the main problem(s) that are holding-you-back

One little caveat to go along with this: You need to be able to deliver on these five points. If you don’t, then you honestly deserve to get resistance from your folks. They will believe that either you a) cannot back it because this info is not legitimate, or b) you aren’t willing to put-in the effort to back-it. Basically, you don’t really believe in it, but you expect them to care more than you.

At the end of the day, people really want to take pride in their work and don’t want to do senseless stuff. If they can see the carrot, and understand that carrots are good, they will reach for it.

If they truly understand things, they may even contribute additional ideas and become invested in solving the root of the problem. They may even feel inspired to solve other problems. How cool would that be?

Posted in IT Psychology, Professionalism, Team | Tagged , , , , , | Leave a comment

Refactoring code that is too big

“If your code is so big that you need Regions to collapse areas of it, then your code is probably too big and you should consider refactoring it”.

I’m sure everyone has encountered a programming task, where someone wrote a huge page or library or function, etc. and you had to maintain it. This kind-of feels like you’ve been dropped in the ocean at night. You can’t see the shore and it is hard to determine which way to swim. Even choosing to swim west, might be pointless if there is a current going east.

Fundamentally, the concept of refactoring large files into smaller files seems logical. So, when I see a really large file or function, my first inclination is to dive-in and refactor it.

I recall one particular time, when I took a large class/file and started refactoring it. I cut large chunks of code from the file and pasted it into new files and connected them back together by making calls between them. As I did this, I found that some of the code was stateful and relied on local (private) variables and properties. So I had to pass those into the functions that I just moved. As I did this, I realized that it was all becoming tightly coupled.

Once I was done, I evaluated what I had just done: refactoring this class/file took a bunch of time, I changed a lot of code (which added risk) and the finished work was tightly-coupled (not ideal). In the end, the refactored code seemed to work fine. So I guess it was maybe worth the risk. I still wasn’t sure how much value I had actually provided. It could be argued that I added or subtracted value.

So essentially, what I found is that refactoring was not so bad in functional (modular or non-OO programming). You just cut the code in half or in tenths, and you are done. However, in OO, you can’t just split up the code in “an object”. Some of the fundamental nature of OO programming is encapsulation. Encapsulation basically means that your object needs to contain all of its own code and state (variables). Splitting it up is a clear violation of OO principals, unless you are pulling the them into another class, which is independent of the other classes (loosely bound).

Sometimes an object wraps something really big. Sometimes, you can’t just refactor it and make it smaller. And sometimes, when you refactor it anyway, you end up with utility libraries and static classes and functions, that merely spread the mess around and it is no-longer very true to OO design.

Another down-side to this style of refactoring is when you refactor without consolidating any code. In that case, your code seems smaller because you have seventy files that are ten lines long, but still have seven thousand lines of code. When you step through the code, you start to get lost in the seventy files that your logic traverses. Good luck keeping track of that. I don’t really believe that it is an improvement of any kind.

The most certain way that you can tell that you have over-factored a function/class is when you have subs/functions where you are passing dozens of parameters into it, or if you have to use ByRef variables (you change the state of a param, rather than returning it as a result from a function). This is terrible and is evidence that your code and logic is fragmented and will be more-difficult to maintain now.

Most developers who encounter this kind of problem pick one answer: “This should be rewritten”. However, all truly experienced programmers will tell you that a rewrite is very unlikely to produce a better outcome. It will just burn through a bunch of time & money.

My point is this: some blocks of code are just big. Before you spend months working on the perfect refactor, think about the ROI that you will get. Just because “the experts are saying it”, doesn’t mean it actually makes sense or is practical in most circumstances. Please get a grip and show some judicious discernment. Then discipline yourself to pick the low-hanging fruit (if there is any). Get that done and then step away from it, and call it a day.

You don’t have to solve every problem. Pick your battles. Know when to be elite and when to be efficient.

Posted in Lessons Learned, Optimization, Professionalism, Programming | Tagged | Leave a comment