Total Cost of Ownership - a Story

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/total_cost_of_ownership__a_story.htm]

A company needs some software service that isn't their standard-line of business, so they outsource it to you (and your company) and pay for the application. So far, so good.

But then, as the client is using your app, they're struggling on the employee search filter page. After getting frustrated for five minutes, they ask their coworker if they know how to work it, just to make sure it's not some obvious mistake. After neither one can figure it out, they think it's an error (not the friendly name "bug", but an error, and to them a critical and fatal one).

So, they phone your company's customer service rep, who rushes around trying to find a fix, and inevitably has to get back to them. After a string of High-Priority emails between the customer service rep and several maintenance developers and documentation writers, the customer service rep is confident that this is an "issue" (perhaps an "error", but issue sounds less blamable), they apologize to the client and offer that it will be fixed in the next release - several months in the future. "No deal" the client says, "We need this now."

Your company's account manager (who oversees that account) gets involved, trying to work their magic diplomacy to make everyone happy. But the client insists "we need this - the thing simply will not work for our business cases without it." So, your company being one that always puts the customer first, pulls in an executive who directs the issue to a developer who can make a fix right away, and hopefully get out a patch or hotfix.

The developer drops whatever they were doing, losing all the momentum they have built up for their current task, and re-mobilizes to hunt down this issue (which is in code they never even wrote). They coordinate with a product manager to make sure they understand the exact new functionality. After spending hours coming up to speed, and ensuring they can reduplicate the bug, the developer finds a fix. It was one line that needed to be updated. Indeed, it often seems that these types of bugs are "just" one line.

The code is sent as an emergency item to QA, who redeploys their environment, confirms the fix, does a little regression to make sure it didn't break anything else. After all this, they then sends it to IT, who stays late that night to make a special patch deployment.

The team's work pays off - thanks to hours and hours from the customer service rep, the account manager, the product manager, the developer, the QA tester, and IT - one line of code has been fixed in production, and the client is happy again. For some development shops, this is actually optimistic, as many places wouldn’t just dismiss it as "a small issue" or have to wait to the next release instead of patching right away.

However, while it's great that the team was flexible enough to handle this change, think of the cost. Here's the problem. Fixing that one-line bug after production release could have easily cost hundreds of times more resources than just doing it right the first time. If it took the whole team 16 people-hours, and the original developer could have caught it with an extra 5 minutes of unit testing, then this was a colossal waste of time. The problem is that many developers insist (and managers cave in to) that "I just don't have time" to do . And then from their short-sighted perspective, they've saved the company time because they got the feature done 5 minutes earlier. However, the total cost of ownership - not just the developer creating the initial feature, but everything else involved (like QA and maintenance) is what really matters. If a sloppy developer can shortcut 5 minutes, only to waste the team hours later - whose really coming out ahead? Answer: Your competition.
 

Book: C# 3.0 in a Nutshell

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/book_c_30_in_a_nutshell.htm]

I recently finished a casual read of Joseph & Ben Albahari's good book C# 3.0 In a NutShell (by "nutshell" they mean 800+ pages).

 

They do a good job of including two audiences - those new to programming (who need C# syntax and the basics of an array explained), and those familiar with C# who just want to see the new stuff. I found the chapters on Linq and Ling-to-Xml very instructive.

 

They also then give a healthy chapter to each of the main parts of the framework. To be able to jump from language design to Linq to System.Net to Reflection to Xml to Serialization and beyond is an impressive feat. I think having that kind of broad knowledge gives the developer a powerful tool belt. Besides the basics (like xml), there are simply cool tools and process that you can never create unless you understand reflection, diagnostics, networking, streams, and even threading.

Real life: Automation and teaching your kids

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/real_life_automation_and_teaching_your_kids.htm]

We have 2.5 kids. Cute little bunch - but very dependent on Mom and Dad. Every few minutes, they come back to us, needing something. Of course, our goal is to teach each kid to just take care of things - brush their own teeth, pick up their toys, eat their food, etc... And then, ideally they could string all these acts together and just take care of themselves for some time on end. Especially as the older one learns to do this, it frees us up to focus on other things - like the young one throwing toys at the wall. Especially with the second, and third, you realize that you don't scale - there are too many kids per parent - you need to make them self-sufficient, at least for a time.

 

This reminds me much of automated process. Both ideally could be on autopilot. Both come back to me asking for help (my console app burped on a bad xml input file, my service didn't handle the machine restart, my build script crashed on spaces in a filename, etc...). While it's cute to initially have your pet application that you baby-sit and marvel in awe of how well it churns through those calculations, soon you'll have a new pet application, and you'll need that first one to be self sufficient.

 

One more similarity - you hope that one day they'll both make you rich. The kid will strike it big and take care of Mom & Dad in their old age, and those .Net applications will keep delivering business value and keep you employed. [just kidding]

 

Although, of course the analogy breaks down because the kiddies are so much cuter, but you get the idea...

Why I'd rather be an optimist

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/why_id_rather_be_an_optimist.htm]

Some programmers take pride in calling themselves either an optimist or a pessimist. Both have their positive and negative stereotypes: The out-of-touch bubbly optimist vs. the encouraging can-do optimist; the always grumpy pessimist vs. the face-the-facts pessimist.

Part of it is that most producers tend to be optimists, as it takes a can-do attitude to carry out the positive act of creating. Most critics/complainers tend to be pessimists, negatively and constantly pointing to the shortcomings. However, these are not equal positions. The producer can produce without the critic, but that the critic needs someone else to produce something so that they have something to criticize. In other words, the producer (usually the optimist) does not need the critic (usually the pessimist), but the critic needs the producer. It's like riding a sled down the hill vs. pulling it back up - they're not equal tasks; one is much easier. Likewise, a room full of complainers will never actually build something. While constructive feedback is great, a purely negative feedback loop isn't constructive. It also will get on other coworker's nerves.

Some pessimists think they're providing a great service by always pointing out the flaws, lest the optimists lose touch with reality. However, "reality" doesn't need any help in reminding developers about the facts of life. It's got the compiler, project plan, and end-users to do that.

Ideally, as with everything else in life, there would be a good balance. But, everything considered, if I had to choose one I'd rather be an optimist. It's been said that "The pessimists may be right, but the optimists have more fun along the way."
 

 

Random quotes that could apply to development

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/random_quotes_that_could_apply_to_development.htm]

Here's a list of seemingly-random quotes that could apply to development. I don't recall the sources for each of these. Every now and then, it's good to have a good quote handy.

• "Talk is cheap."

• "Better to try and fail than to never try at all."

• "I prefer my way of doing it to your way of not doing it."

• "If all you have is a hammer, everything looks like a nail." (good for showing how new tools can expand your thinking)

• "The pessimists may be right, but the optimists have more fun along the way."

• "You can be right, or you can be happy."

• "Give a man a fish - feed him for a day; teach a man to fish - feed him for life."

• "Consider it done." (very nice thing to say to your manager when asked to take care of a task)

• "Easier said than done."

• "At some point, you just need to jump into the arena."

LCNUG: SharePoint Authentication: Inside the Hybrid Provider

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/lcnug_sharepoint_authentication_inside_the_hybrid_provider.htm]

At the LCNUG last night Chris Domino presented on Sharepoint. He's a SharePoint superstar, and it showed. The LCNUG still is a smaller group, so we could ask a lot of interactive questions. I especially liked a dialogue about document versioning history in SharePoint vs. saving words docs as xml and then storing those in normal version control (like subversion).

 

Overall, a very good night. I think it also marks the half-year mark for the upstart LCNUG group.

Bad Interview Question: What is your greatest weakness?

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/bad_interview_question_what_is_your_greatest_weakness.htm]

For technical interviews, I think "What is your greatest weakness" is one of the dumbest interview questions ever. It's like the recruiter thinks they're being so smart and sneaky ("ah ha, this unsuspecting candidate will reveal all their shortcomings as I judge them"), but it really misses the point.

 

Problems with this question:

• If the interview cannot determine your weaknesses from normal interview questions, are they really weaknesses? It is part of the recruiter's job to determine your weaknesses, and by directly asking you, they're essentially asking you to do their job for them.

• Most people aren't even aware of their biggest weakness, especially because human nature always sees ourselves in the best light possible.

• It's an abrasive question that puts the company in a bad light. People want to talk about their successes and how they'll add value, not their mistakes.

• Does the interviewer actually expect the candidate to tell the complete truth about their own flaws?

• To avoid ivory-tower syndrome, (in my opinion), recruiters should not ask behavioral questions that they themselves are not prepared to answer.

• It's a dead-end question that prompts the recruiter to pick the "least of the evils" - if you're just discussing your negative qualities, you're not going to look like a positive candidate.

• If I knew my weakness, I'd already be fixing them.

• It's very dull, and shows no creativity from the interviewer.

• This sort of question isn't going to impress a candidate. Often, the interview is really two ways, with many companies all trying to woo the star candidates.

Really lame replies:

• "I work too hard", or "I try to hard". --> anyone who has been around can see straight through this.

• "I do such a good job that it makes everyone else envious of how great I am."

• "I don't really have any flaws." --> everyone has limits, which is very different than saying that you do have shortcomings, but they occur mostly in other, unrelated fields, or long ago when you first got started.

• "I've never been in a position with enough influence to do any damage, so I'm not sure."

Possible good replies:

• Humor: "You know, you could get a really good answer for that if you just talked to my wife." (or husband/spouse/significant-other )

• Serious: "While I've made mistakes in other fields, like buying my first car, for years I've been putting most of my eggs into the software engineering basket precisely so I don't make huge costly mistakes anymore. But we can discuss my early car-buying experiences if you'd like."

• Confident: "Let's have an interview and you tell me."

• Change topic: "Here's how I've dealt with mistakes that the company has made, and turned them around to be profitable..."

• Pick a small, past event: "When I first got started, 10 years ago, I used VSS for source control. The default single-user lock model really messed up our multi-team project. Now I'm happy that we always use Subversion."

• Sarcasm: "My  biggest mistake ever - like single-handedly causing the stock market crash of 87 - I don't do those kinds of things anymore." (you'd need more charisma than I have to pull it off)

• Smart Aleck: (when you don't want the job) pick a topic that's way over the recruiter's head. I'm trying to think of an impressive example, but I'm sure the readers of this blog would just tell me how simple it was.

• Smart Aleck (when you don't want the job): "What would you consider a failure? Perhaps you can tell me some of your greatest failures so I know what kind of things you're looking for."

At Paylocity, I don't think I've ever asked a candidate this. Instead, I'll ask "what areas of development do you enjoy", or "what areas do you wish you had an opportunity to learn more about". The goal is not to trick people with dumb gotcha questions, but (for me) to figure out where their passion is. I prefer a positive approach of "what are you passionate about" as opposed to a negative approach of "what are your flaws". At Paylocity, we don't ask people to do what they're bad at, we ask them to do what they're good at - i.e. play to their strengths, not their weaknesses. Also, the interview should be an indicator of what the company is about, and what kind of company goes around asking their employees "what do you suck at most"?