VB3 is just fine for running your business

http://discuss.joelonsoftware.com/default.asp?joel.3.552365

“… all those cheapskate companies running said VB3 app for 15 years will have nowhere to go, because their shitty app won’t run on it and they won’t pay to have it redone with modern tools.”

You’ve got some typos in there. Let me fix those for ya:

“…all those fiscally responsible companies running said VB3 app for 15 years will have nowhere to go, because their well-written app that has performed its intended function without fail won’t run on it and they don’t need to pay to have it redone with modern tools.”

Analogy time:

I’ve got a 25-year-old fridge in my kitchen. Even if a new one saves me 50% of the electricity used it would take about 13 years to pay back the cost of buying the new one. And don’t talk to me about the environmental cost of that wasted power, since the impact of manufacturing the new one dwarfs the power used over its lifetime.

If you think you’re saving money, or helping the environment, by scrapping working appliances in favor of newer, more-efficient ones, you’ve fallen for someone’s marketing plan. Just like all the people who want to re-write functioning apps in the cool new language du jour.

How to Fail by Succeeding

Dave Christiansen over at Information Technology Dark Side is talking about perverse incentives in project management, which he defines as:

Any policy, practice, cultural value, or behavior that creates perceived or real obstacles to acting in the best interest of the organization.

One class of these perverse incentives comes from the methodology police. These departments exist to turn all processes into checklists. If only you would follow the checklist, everything will work. But more importantly, if you follow the checklist you can’t be blamed if you fail.

How’s that for perverse?

A great example is that there is rarely any incentive to not spend money. Before you decide I’m out of touch with reality, notice I didn’t say “save money.” I said “not spend money.” Here’s the difference.

IT by the numbers

Let’s say you do internal IT for a company that produces widgets. Someone from Operations says that they need a new application to track defects. If you follow the checklist, you:

  • engage a business analyst, who
  • documents the business requirements, including
  • calculating the Quantifiable Business Objective, then
  • writes a specification, which is
  • inspected for completeness and format, then
  • passed on to an architect, who
  • determines if there is an off-the-shelf solution, or if it needs custom development.

At this point you’re probably several weeks and tens of thousands of dollars into the Analysis Phase of your Software Development Lifecycle. Whose job is it to step in and point out that all Ops needs is a spreadsheet with an input form and some formulas to spit out a weekly report?

Let’s put some numbers to this thing.

Assume the new reporting system will identify production problems. With this new information, Operations can save $100,000 per month. A standard ROI calculation says the project should cost no more than $2.4-million, so that it will pay for itself within two years.

Take 25% of that for hardware costs, and 25% for first-year licensing, you’ve got $1.2-million for labor costs. If people are billed out at $100/hour – and contractors can easily go three to four times that for niche industries – that’s 300 man-weeks of labor. Get ten people on the project – a project manager, two business analysts, four programmers, two testers, one sysadmin – and that’s about seven months.

If everything goes exactly to plan, seven months after the initial request you’re $2.4-million in the hole and you start saving $100,000 per month in reduced production costs. Everyone gets their bonus.

And 31 months after the initial request, assuming nothing has changed, you break even on the investment. Assuming the new system had $0 support costs.

But what if …

Way back at the first step, you gave a programmer a week to come up with a spreadsheet. Maybe the reports aren’t as good as what the large project would have produced. You only enable $50,000 per month in savings. That week to produce it costs you $4,000 in labor, and $0 in hardware and licensing.

You are only able to show half the operational savings, so you don’t get a bonus. You don’t get to put “brought multi-million dollar project in on time and on budget” on your resume.

And 31 months after the initial request, the spreadsheet has enabled over $1.5-million in operational savings.

How to avoid analysis paralysis in the interview

Prepping for a job interview is a little like a politician prepping for a debate. There are certain questions you can count on hearing, and you prepare canned responses to them. In the job interview these would be things like, “Why did you leave your last job?” and “Where do you see yourself in five years?”

Then there are the technical screening questions. They’ll focus on your experience and knowledge. Typically you’ll get some basic stuff to begin with, just to see if you really did all those things you put on your resume.

Then you start getting to the interesting questions. The ones that don’t have a clear “right” answer. Or do they? Does the interviewer have something specific in mind? Will I blow it by not coming up with the right answer?

Take these two technical questions as an example:

  1. When or why would you consider using an RDBMS (like MySQL etc) as opposed to a desktop database (sqlite etc)?
  2. When creating a function how many parameters would you allow that function to handle?

Programmers tend to enter the field, and stay in it, because they’re good at finding right answers. Computers are (mostly) deterministic. The upside for the programmer is that they know with certainty when they’ve solved a problem. The downside is that they know with frustrating certainty when they haven’t. They can’t just dress up “because I said so” in reasonable-sounding logic and turn it in. Their program has to actually work.

But the questions above don’t have right answers. They aren’t intended to see if someone knows how to implement a given solution. They’re intended to see if someone knows how to ask the right questions to choose the right solution.

Anyone can look up a linked list implementation, or a quicksort. Most interviewers are more interested in identifying the guy who can figure out which one to use.

For the parameters question above, I’d want somebody to state a basic rule of thumb — probably something from 3-10 “feels” like a reasonable starting point. But they should also explain their reasoning, which might be along the lines that too many parameters is likely to indicate too much going on in one function. Then possibly present an exceptional case where a high parameter count would be preferred.

Maybe there would be some discussion around passing an array of name/value pairs instead of multiple individual parameters, or named parameters, default values, etc. Or pro/con on passing all the values for an object in the new() declaration, vs. a basic instantiation and then multiple set() calls.

These specifics are not the “one right answer”. They’re examples of the kind of answer I’d hope to hear. If I asked you the question and you couldn’t either float some ideas or ask some reasonable questions, I’d take it as a sign of lack of experience. Interviews are not a multiple-choice test, they’re essay format. If the interviewer or the candidate acts like it’s multiple-choice, they’re wrong.

Trying hard to not get it

If you’re interviewing people for entry-level jobs, maybe you do just need to know that the candidate can implement a particular pattern. Once you get past entry level, you’ll want to see that the candidate can identify which pattern they should implement. Best is to find a candidate who knows why to choose a particular pattern. Which means they know other patterns and why not to choose one of them instead.

You can make it through a class in school only learning the one technique that you’re going to be tested on. That’s why entry level people aren’t trusted to make choices, just do what they’re told. Once you get out of the classroom, you have the freedom to re-invent everything, making the same mistakes everyone has made before you. The more ways you’ve seen to solve a given problem, the more choices you have. I’m not interested in finding someone who’s always going to choose the same solution as me. I want someone who knows the general principles and how to prioritize competing goals.

But some programmers will get nervous, and others downright hostile, if you ask a question without a clear right answer. As far as they’re concerned, it’s a “bad question” that you shouldn’t even ask. Apparently any question where the answer starts with “It depends” is a trick question, and even asking it is an insult.

How you should answer

Remember those courses you took where the instructor would tell you to show your work? Even if the answer was wrong, you could get partial credit for having the right approach. When interviewing it’s all about showing the work. The “right” answer is almost incidental.

But sometimes there is a right answer. Doesn’t that matter? Absolutely. And knowing whether you’re dealing with one of those questions or not is an important skill.

If my goal is to evaluate whether someone knows how to clarify an incomplete requirement, I don’t start by telling him, “Now I’m going to give you an incomplete requirement to see if you know to clarify it.” I ask a question as though there is a right answer and see what they say.

So maybe you read all of this and think that now you know what I’m looking for. That doesn’t help you with someone else who may have a different plan. The good news is that it doesn’t matter, as long as you answer truthfully.

If the interviewer is looking for a specific answer and you give multiple alternatives, you may be giving a better answer than what he expected. Or maybe he’ll disagree with your reasoning and decide that you are wrong. Do you want to work for someone who will shoot down your ideas?

Or the question was supposed to be open-ended but you give a single definitive answer. A good interviewer will prompt you to explain, maybe even asking about specific alternatives. Did you have a good reason to discount those answers? Explain it. Did you not think about that? Admit it. Maybe you’re really not a good fit for this position.

Sure, you need a paycheck. But unless you are desperate you also need a good fit. If you and the person you’ll be working for don’t see things the same way, you won’t get that fit. So instead of trying to overanalyze what the interviewer “really meant”, just answer as honestly and completely as you think you can. If you, the interviewer and the position are a match, all that’s left is to talk about the money.

The program is not the product

Managers want programs to be like the output of a factory. Install the right robots and tooling, start the process, and good software comes out the end.

WRONG WRONG WRONG WRONG WRONG WRONG WRONG WRONG WRONG WRONG!!!!!! (Can you tell I disagree?)

Nearly everyone who makes the factory analogy misses a very fundamental point: the program is not the product. For one thing, unless you work for a software company selling shrink-wrapped software products you aren’t ever selling the program. Conventional wisdom says most programmers actually work for internal IT, so it’s safe to say most programs are never sold.

Businesses don’t want programs, they want credit reports … and loan contracts … and title searches … and purchase orders … and claim forms …

So what is the right analogy? The program is the assembly line! So measuring bugs in the program is wrong. Even comparing compiling to manufacturing — which is still better than comparing programming to manufacturing — is wrong. What you should be looking at is the output produced by the program. Is your program a website? Measure the number of pages it can produce per unit time, without error. Is it an editor? Measure the number of pages it can spell-check per unit time, and with what accuracy.

When measuring the output of a manufacturing process, you literally shouldn’t care what the process looks like, nor what tools are used, so long as it consistently produces the same output. This is not to say the process and tools don’t matter. A bad process may be prone to unexpected failure. Tools may be harder to maintain or have a shorter service life. You may be locked into a service contract with the manufacturer. And coincidentally [ahem] all these factors apply to software.

So yes, programming can be compared to manufacturing. As long as you remember that the program is not the product, the program is the assembly line.