Owning your mistakes

As you read this, I would like you to picture me wincing and making a sour face (like I just bit a lemon or something). This is because what I am about to say is not very pleasant. It is hard and it is uncomfortable and humbling. Ready? … If you make a mistake, you need to own it.

It stings my mouth a little, just the very concept of this. Because when I make a mistake, I am never proud of it. It is embarrassing and I hope people will quickly forget it, and we will never speak of it again. But I have to be a little careful about how much I do that, myself.

So, why own something that is going to make you feel so bad?

  1. Humility. The most vivid example that I can think of is from the movie Fight Club. Tyler Durden gives an assignment to the people in project mayhem: go pick a fight with someone and intentionally lose the fight. At first I thought maybe it was meant to test people’s loyalty, or honesty.       Later, I realized that it teaches the same thing that a karate school does: You will not always win. Therefore, you must learn to lose with dignity and humility. In so many words: learn to take it like a man.
  2. Integrity. You know what is easy? Blaming others, or lying. However, when somebody does that to you, don’t you feel disgusted by that person? It tends to inspire foul language. Pretty much, I don’t ever want to be that sort of person. Gosh, being the opposite of that, is what I really want to be. So I guess I really should blame [the opposite of someone else]. Three fingers pointing back at me, right? Better-off not pointing in the first place.
  3. The steps. The first step to solving a problem is admitting there is a problem. If you cannot/will not admit your part in it, then how will you ever expect to improve? What will prevent this from happening in the future?
  4. Growth. If you own the mistake, it will burn, but that burn is meant to motivate you to want to change. Embrace it and use it to move yourself to a better place. Next time you think about playing with fire, you will remember the burn and you know you have to own it each time. Is it worth-it this time? It makes you think twice.
  5. Respect. If you are the kind of person who is willing to take the blame for stuff, then people will respect you. It takes guts, and people know it. I find it pretty easy to follow someone whom I respect.

Face it: people make mistakes. They do. You do, I do, everyone does. Owning your mistakes is never fun, like getting your teeth scraped, or rehabilitative physical therapy. You just have to do it, because it is the right thing to do. Stay leet my friends.


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

Tech debt and vulnerabilities

*** Disclaimer: This is not about my current project. It is about all projects, everywhere. ***

One kind of tech debt, which could cost you deeply, is ignoring upgrades. 

I know the philosophy of “if it ain’t broke, don’t fix it” can seem pretty appealing to some.  After all, maintenance costs money and introduces risk.  If you want to avoid those two, try to do less stuff, like unnecessary maintenance. 

Software upgrades are not patches.  So upgrading some software, to the latest version (or service-pack) sounds optional. And by “optional”, we all know that means “we can live without it”.  You figure that you should be covered because after-all, your software runs on systems which are supported by reputable vendors. The vendors have it covered (hence the term “reputable”). The server-admins have applied every patch that they were sent. So I guess everybody is good-to-go.  No worries. Right?

That is not exactly accurate.  There is a thing called a “zero-day exploit”.  What this means is that some bad-guy out there, might discover an exploit before the good guys do.  Then the bad guys will share the exploit info with their bad friends and they will have a field-day with it.  Eventually, each person tells two others, who tell two others, and so-on.  Eventually, a good guy hears about it and reports it, but until that happens, the bad guys have a big advantage. I know it sounds like there isn’t really anything you can do about this, but there is always a little extra.

Outdated technologies are notorious for containing security holes.  The reason for this is because we have learned so much in the past twenty five + years. The original internet programming languages weren’t written to be secure because the inventors never imagined that people would think of exploits like they have. In contrast, people today are fully aware of these hacking techniques and plan improvements to the languages so they are inherently more secure and less vulnerable in-general. It is actually much harder for a programmer to make a mistake which would create a vulnerability. Modern frameworks just don’t work like that any more.

So what should you be doing about it?  Well, my point is that technology is not just patches.  It is a spectrum of stuff.  That includes: using the latest OS, using the latest DB, using the latest version of any programming language, frameworks, libraries, dev tools, etc.  Even if something is still working, you should maintain it by keeping it updated.  In a word: vigilance.

So, if you ever think about skipping the next upgrade or two, just be aware that you are essentially neglecting vulnerabilities.  You take a chance either way.

Posted in Maintenance | Tagged , , , | Leave a comment

Stupid effing owin won’t go away

[burst of profanity omitted] I’m writing this while I’m angry, so bear with me for a moment. Hopefully, this advice can spare you the agitation that I’m experiencing right now.

I wanted to do something fairly simple today (it doesn’t matter what).  I was in a hurry. No biggie, right?  I figured I would just create a quick little util with VStudio 2015.  “Hmm. Lots of choices”.  I figured a WEB API app should be pretty simple, so I started there with a quick REST project.

Get this: It created some 12+ folders and 60+ files with references to another 25+ libraries.  Well um, no!  That wasn’t quite my idea of simple. So I chucked that idea.  I guess maybe I’m spoiled by the good old days when a simple project meant one file, maybe another for code-behind and maybe one more for config.  Three files.  Now that is simple.  Is that too much to ask?

Maybe I started with the wrong project type.  So, I started over and created a “Classic ASP.NET” project.  It is a classic, right?  Can’t be overly fancy.  This is what I needed, right?  Well, I was not quite satisfied when it created much less noise. And by “much less”, I mean: only 10+ folders, with only 40+ files and 20+ references.  (deep sigh).

Well, I know most of that stuff in those two simple templates, appears to be completely unnecessary.  So instead of starting over and picking yet another project-type, (to give me five dozen more useless files), I decided to hold with “classic”.  I would simply remove/omit/strip-out everything that I know I wouldn’t need.  Take that!  Ha!

(rip, strip, omit, bim-bam-done).  Now that was easy!  Ready to click “run”.

When I did, the goshdarn page came up complaining about some stupid OWIN crap.  Well darn it. I just ripped that crap out. So why is it still complaining.  Oh yeah. Web.config.  Duh.

I opened the web config and there was a bunch of useless references and stuff. Ah ha!  So I scraped out all of the stuff that I knew I didn’t need.  That cut it down from 400+ lines to about 25.  (smile)

Not so fast. The dang thing still was complaining about OWIN. So I recompiled.  …Nope.  Still OWIN. … Clean project, search all folders, files, even open the .CSPROJ file in notepad. Nada.  … What the h3# else could it be?!

Eventually I found it.  The problem was caused because VStudio dumps a bunch of stuff into the /bin/debug folder when it builds, but doesn’t friggin know to remove it when it is removed from the project.  “Clean” doesn’t even remove the stink.  You have to manually go into your /bin/debug and flush those clunkers yourself.  I’ve never seen a project do something obnoxious like that before. Which is why it had me stumped for a few hours.

I’m done being mad now. I’m going to go walk-it-off and then go back to work.  (big sigh again). I hope my solution saves you some time and frustration.



Posted in ASP.NET, Errors, IT Horror Stories, Programming | Leave a comment

The right words

It is worth it
to take the time
to find the right words
to use.

there is often
not enough time
to find the right words.

The best time to find them
is before you need them
that is when
you have plenty of time.

Be prepared.
Practice as often as you can.
Then when you need the right words
you will already be ready with them.

On the other hand
if you practice with the wrong words
or bad words
then those will be the first ones to come to mind
or maybe the only words

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

Down time

College is designed to teach you a bunch of stuff, but one of the biggest lessons comes from “finals week”. This part of the semester also includes the week before finals, when nearly every goshdarn class seems to have a big project due (like they are the only class that you are taking). The double-whammy of big project + cramming & final exams, is a pinnacle. These two weeks are grueling and really test your mettle. You work your butt-off and spend seemingly endless amounts of time, studying and obsessing about your classes, all so you can earn the best grade possible.

The good news is that this process teaches you a very valuable skill. In your real job (and career, overall) you will periodically experience intense periods, just like finals week. Hopefully, it doesn’t happen more than 2-3 times per year.

In college, after finals, there is always a week of downtime. Students are supposed to use this time to catch up on everything that was neglected during the previous two weeks, and it is a chance to re-charge. It is also a period for reflection on how the previous semester went, and to contemplate what could be done next semester to improve things. I suppose there is even some time to celebrate your accomplishments and share the experience with your colleagues.

In your career (after college), you don’t usually get down-time like you did in college. It is the job of management to make sure that your workload does not consist of peaks and valleys, like you had in college. Those are not good for people and it can impact morale. However, if you are a programmer, this is naturally going to happen anyway, because it is part of the lifecycle of some software development processes (methodologies).

If you ever get some downtime, you DO NOT want to treat them the same way that you did in college.

Things to not do: (aka “Bad”)

Sleeping-in, partying, showing-up late, leaving early – Don’t even think about it. When there is down-time at work, management will be watching you closer than ever. There is a saying “idle hands are the devil’s workshop”. This is a test to see who is responsible and who is unable to manage themselves and behave consistently like an adult. You will not be warned about this. If you fail this test, you will be blind-sided weeks or months later. For some strange reason, all of the good work that you have done won’t seem to matter. You will be passed-over without any explanation. If this has ever happened to you, then please commit this warning to memory: Don’t ever think that nobody is looking. You are always being evaluated. Always. These are the moments where you will stand-out in a good or bad way.

Things to do: (aka “Good”)

Tech debt resolution – “You got time to lean, you got time to clean.” We all know that every dev project will contain some technical debt. Now is the time to assess it and catalog it. Make a wish list and prioritize it. Time is going to fly-by, so don’t put it off, and don’t be informal about it. Get management involved so they understand, or they might mistakenly think that this is some kind of boondoggle, or maybe it’s just “for the cool points” or something. Take it seriously, and help them take it seriously too.

Brainstorming – Now that the project is being used by real people, folks are going to become more-aware of what works and what is just awkward or downright frustrating. Start seeking feedback and start developing a list of suggested improvements.

Log monitoring – You are not a hack, so your system has some tracing and logging mechanisms. If anything goes wrong, you need to keep your nose in those logs so you know it before anyone else does. Watch PerfMon like a hawk. Find the next bottle-neck or two and be ready to fix any flaws promptly.

Process improvement – In every project there will be some good times and some bad. Now is the time to assess that while it is all fresh in your minds. Write it down and contemplate it. Just like the lull between semesters, you can use this time to figure out how to begin and execute the next project or phase better than the previous. Find root-causes, propose process changes, research new technologies and toolsets that could improve your next project (or phase/sprint).

Utility / internal / support apps – Once you start supporting your app, you start realizing that it would be easier if your app had better logging, reporting, more-granular tracing, better info, etc. It can be pretty satisfying to write an app for yourself (in a day or two) that makes your (or your whole team’s) job simpler.

Learning / self-improvement – Be careful about this one. Most managers will expect that you are already doing this at home, “on your time”. So if you are doing your homework at work, you are one-step-short-of doing nothing, or slacking, etc. It might seem like it is better than nothing, but there are probably things that you could be doing to bring the “wow” instead of just not-sleeping at your desk.

There are more things, but I think you get the picture. This is what leet looks like.

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

Testers, bugs and the end-of-the-world

*** Disclaimer: this is not about my current project. It is about all projects, everywhere. ***

If you are a developer, and you have worked much with professional software testers, you will love & hate them.

You will love them because they can do something that you struggle-with: they find the bugs that you missed. Everybody wants flawless software and as a developer, you probably have your limitations. You are good at developing, but you think like a sane, reasonable person, … and well, that is just not good-enough, when it comes to testing.

A skilled tester will have the extraordinary ability to think of whacky, cuckoo, way-out-of-the-box, “WTH” kinds of stuff. It is unnatural for a developer to think like that. Therefore, when a tester finds some nutso bug, or even something super-obvious, the developers feel grateful that it was caught before it went to production.

…unless the tester acts a jerk about it.

I guess even that is forgivable. Probably.

Unfortunately, the very nature of professional testing, is eventually going to condition testers to be jerks. That sounds a little harsh, I know. Let me explain.

So, when a tester finds a bug, he/she has done their job. “Nice one! Keep it up!”. Every now-and-then, a tester will find a “show-stopper”. This is a kind of bug which would wreak havoc on your system and/or undermine a user’s confidence in your software. Sometimes, it can be something simple, like an error message, or an awkward validation message, and sometimes it can be something subtle, like a security rule which was implemented wrong. Regardless, when a tester finds a “show-stopper”, the response is usually celebration by the test team and frustration by the dev team, and management.

As a tester, your first project will have a few of these discoveries, and they will all seem very exciting and emotional. Over time, a tester will accumulate (trophies) tales about the worst bugs ever found and just how serious they were, “That was a serious flaw! What a catch! …and it was truly a last-minute discovery. …blew our go-live date.” For a tester, these stories are big accomplishments and telling them feels great, because you saved the day.

Not every project will go that way. Developers are clever folks. They also have their own tales about solving these “last minute show-stoppers” and how stressful it was. They will learn the patterns of the bugs, and take measures to ensure that they don’t happen ever again. They will learn from their mistakes and mature in their processes. They will eventually make fewer mistakes and produce better programs. This is great for the developers, but for the testers, not so much.


If you are a tester who has found dangerous/critical/catastrophic/project-killer bugs, those shiny trophies become part of your identity. They make you feel validated. You sacked the opponent’s quarterback, or blocked the field-goal kick. You saved the big game and you feel great about it. On your next project, you expect the same, or better. You want eggs for breakfast and those developers are like chickens in a coop. Grab a basket.

Managers mean-well. It is their jobs to keep you motivated and hungry. They know that winning a trophy feels good. A word or two of encouragement can’t hurt anything. Could it? “Remember when you found that epic bug? When are you going to find another one like that? You can do it!”

Let’s face it, a tester can only find bugs which are there. If there are no serious bugs, then serious bugs won’t be found. As a tester, you understand this. So, when there are no serious bug discoveries, everyone has a reason for celebrating, except for you.

If this continues, you (and possibly your management) will start to doubt or second-guess your skills. Could there be a big bug or two in there, but you didn’t find it? You might even get superstitious and develop a feeling that there must be a show-stopper in there. Some people even resort to invalidly applying statistics. Like “for every [X] lines of code there are [Y] flaws and [Z] serious flaws. Therefore, we must have missed something.” It is totally invalid, but it is an easy mistake to fall-into.

Eventually it will occur to you: You couldn’t have missed [Y] flaws and [Z] serious flaws. So, what if you actully did find them but you just didn’t recognize the significance of them. After all, within the current context, certainly some of the bugs are relatively serious. You could be collecting some new trophies right now. Maybe if you had made an appropriate spectacle, folks would be congratulating you. So why not give it a try?

So you try it. You make a bigger deal about one of the bugs that you find.

It is just what the doctor ordered! People have been waiting for this: a bug to sink their teeth into. Everyone high-fives you and calls you a hero. Yes! And to think, you almost didn’t make a big-deal about it. Golly. What were you thinking?!


When a few weeks go-by, and the testers haven’t found a big-one, they will feel some pressure. They will feel deprived of their joy, and it might motivate them to try something to change that condition. After all, folks need their high-fives, right? You see where I’m going with this. …I’m not saying that the testers will resort to blatant hyperbole. (Not initially, at least). However, I’m thinking of a gentler term like “exaggerate”, or maybe “embellish” or “over-react”. Yes sir! All it takes is a little incentive, and the proper rewards.

Repeat this pattern a few times and guess what? It becomes a habit. In some ways it can even seem like an addiction. If a little exaggeration doesn’t satisfy, maybe try increasing the exaggeration a little.

You can see where this is going. Folks will catch-on that some of this might be a little over-inflated. You can bet that the developers are going to call foul eventually. They have their own incentives to show progress and improvement. If it seems like someone is intentionally trying to embarrass them, then things might get a little un-friendly.


Management is eventually going to recognize that something is amiss. At that point they have a few tough options: On one hand, you don’t want to demoralize the testers, because they are thinkers and they need their heads in the game, but if you allow the charade to continue, it will become unhealthy, and it will become more difficult to tell when a bug is just-another-bug or it if actually is the fourth horseman of the apocalypse.

This is when people-skills are key. Usually, this is a management task, but an experienced dev lead can help de-escalate things too.

We all want what is best for our project. Although the-end-of-the-world would be pretty interesting and exciting, I think we are better-off delivering the best product possible, and leave the TV-MA stuff for Hollywood.

Posted in IT Horror Stories, IT Psychology, Testing | Tagged , | Leave a comment

Tech debt, rewriting the whole thing

If you’ve ever looked at a messy program, you might think “we should just rewrite this. It would take less time than fixing this mess”. The logic on it seems flawless, right. You are awesome and your ninja moves are “on fleek”. So naturally, if you rewrote the whole thing it would be monumental perfection and covered in bling. It is hard to imagine anything else, right?

If you don’t see the fallacy in the previous paragraph, I implore you to keep reading, because there might be something that you haven’t considered (or you considered it but dismissed it too quickly).

Anatomy of this nightmare?
Often, programmers will try to convince themselves that tech debt is the result of the following:

  • The program was written long ago, before people learned how to make programs that were not impossible messes
  • The program was written by dim-wits who spent their time pounding square pegs into round holes
  • Nobody cared about code quality and nobody cared enough to check-up on any of it, to ensure any level of quality
  • They used the wrong language / database / server / toolset / framework / methodology. The one that they used is guaranteed to produce this sort of spaghetti
  • The guy in charge was not nearly as smart as me. (followed by a smug/condescending belly laugh)

My response: “in your dreams”

You would be amazed at how easy it is for smart people, with good tools, experience, resources, etc. to make mind-boggling messes. It only takes a few un-treated problems to turn a dream project into a nightmare. Do you know them all? Are you sure? Are you vigilantly watching for them?

How will you avoid the same fate?
There is a saying “Those who cannot learn from history are doomed to repeat it.” So before you start your rewrite, you should take the time to learn where the landmines are planted. Here are a few ways to gather intel on that spaghetti:
1. Code review, architectural review, information review (DB) for everything. Make an inventory the tech debt. All of it.
2. Make a list of the flaws. Group them into categories.
3. Identify the solutions to those categories WITHOUT resorting to “just start over”.
4. Identify the causes of those problems and the steps that lead up to each. Eg. “messy code” – what causes messy code. “no configs” – how did they plan to move/promote from dev to prod?
5. Determine how you will detect those problems early and how to remediate them early

Have you overlooked anything?
There is a saying about the Darwinism of errors “if you produce a fool-proof process, the world will eventually produce a better fool”. Now be honest about how much experience are you building upon. Are you usually just really lucky and smart or resourceful? Is that your plan for succeeding, or have you done this successfully before and have experience with your entire toolset, process, etc? Is this project just like your previous string of successes, or is anything different?

Are you sure?
So, now that you assessed the whole thing and understand what went wrong, how it got this bad, how to avoid or undo it, and have a much better plan, ask yourself: knowing all of this, are you sure it is easier to start from scratch than to undo the messes? Are you sure that it will yield a better ROI, or are you just hoping for something new and cool to do?
Don’t answer too quickly. Take a day or two to think about all of this, and be honest with yourself. Then ask yourself if you would still rewrite it if you were restricted to the same technology stack and platform. Again, maybe deep inside, you just want something new, and that is your primary motivation.

Something that you forgot
I know that you are awesome and your code is always perfect and shiny. We both know that tech debt is the byproduct of timelines. Timelines always start optimistic and turn ugly as you get close to your end-date. That is when your tech-debt accumulates. If you had more time, your app would be cleaner. The reason that I bring this up is because, if you choose to rewrite an app, and think you won’t produce just-as-much tech debt, then you must own a time machine or something. Your timeline WILL get squeezed. It will. And you will make a newer fresher mess.

I hope I’ve been able to persuade you to reconsider. Maintenance programming doesn’t sound very sehk-say, but you can’t deny the value. You just have to have the determination and experience to stick with it.

For further reading, link to Joel Spolsky “things to never do”

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