Principle: Everyone should hit the ground running

Total size of the codebase doesn't matter. Everything a new programmer touches is either shared by other parts of the system or it's not. If it's shared, the new guy probably shouldn't be touching it anyway. If it's not shared, it should be small and self-contained enough to learn it quickly.

Now if you've got a guy in his first month who wants to re-write your DB access class, then you've got a whole different problem than just getting him up to speed. And if he's right about it needing to be re-written, the problem isn't with the new guy.

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.

Get to the point

Dave Christiansen over at Information Technology Dark Side has a good graphic representing what he calls the FSOP Cycle (Flying by the Seat of Your Pants). The basic idea is that when smart people do good things, someone will try to reproduce their success by doing the same thing that worked the first time.

The problem with trying to do this is that every time someone tries to document a "successful process", they always leave off the first step: get smart people working on the project.

Dave outlines several reasons why capital-P Process will never solve some problems. Joel Spolsky described this same issue in his Hitting the High Notes article when he wrote, "Five Antonio Salieris won't produce Mozart's Requiem. Ever. Not if they work for 100 years."

So if Process can't solve your problem, what will? According to Dave, it's simple:

Put a smart PERSON in the driver's seat, and let them find the way from where you are to where you want to be. It's the only way to get there, because process will never get you there on its own.

I'll assume that when Dave says "smart" he really means "someone good at solving the current problem". I could have the world's smartest accountant and I wouldn't want him to remove my appendix. Okay, I don't want anyone to remove my appendix. But if I needed it done, I'd probably go find a doctor to do it. So what Dave is saying is that you'd rather have someone who's good at solving your current type of problem, than have Joe Random Guy trying to follow some checklist.

This isn't a complete answer, though. Some songs don't have any high notes.

In the middle of describing why you should choose the most powerful programming language, Paul Graham writes:

But plenty of projects are not demanding at all. Most programming probably consists of writing little glue programs, and for little glue programs you can use any language that you're already familiar with and that has good libraries for whatever you need to do.

Trevor Blackwell suggests that while that may be changing, it was still true at least until recently:

Before the rise of the Web, I think only a very small minority of software contained complex algorithms: sorting is about as complex as it got.

If it's true that most programming doesn't require the most powerful language, it seems fair to say most programming doesn't require the best programmers, either.

You might notice at this point (as I just did) that Dave wasn't talking about programming, or at least not only programming. The same principle seems to hold, though: Average people can do the most common things with the most common tools. Exceptional circumstances require exceptional tools and/or exceptional people. If only there were a way to predict when there will be exceptions …

The other problem

But let's say we're looking at genuinely exceptional people who have done great work. Should we ask them how they did it? After all, they're the experts.

Well, not really. They're only experts on what they did, not why it worked. They might have simply guessed right. Even if they didn't think they were guessing.

Need another example of false authority? Have you ever heard someone describe a car accident, and attribute their survival to not wearing a seatbelt?

First, they don't know that. They believe it. They obviously didn't do a controlled experiment where the only difference was the seatbelt. Second, even if they happen to be right in this case, statistics show that it’s much more common for the seatbelt to save you than harm you.

So if you want to design a repeatable process for creating software, you can't do it by asking people who are good at creating software.

The other other problem

One change I'd make in Dave's FSOP diagram is in the circle labeled "Process Becomes Painful". It's not that the Process changes. Really what's happening is that the project runs into some problem that isn't addressed by the current Process.

Every practice you can name was originally designed to solve a specific problem. On very large projects, there's the potential to encounter lots of problems, so extensive Process can simultaneously prevent many of those problems from appearing.

But attempting to prevent every conceivable problem actually causes the problem of too much time spent on the Process instead of the project.

That's where Agile comes in. It solves the problem of too much process. Do you currently suffer from too much process? Then you could incorporate some ideas from Agile.

But make a distinction between using ideas to deal with specific problems, and adopting a whole big-M "Methodology". Once you adopt a Methodology designed to solve the problem of too much Process, you face the danger of having too little Process.

Your expert programmers may be the best in the world at the problem you hired them for. But now you want them to do something different. And you have no way to recognize that they're not making progress, because you've eliminated all the governance that came with the heavyweight Methodology.

So what's the point, anyway?

Process is not something you can measure on a linear scale, having "more process" or "less process". Always adding practices -- even "best" practices -- to your current Process is simply trying to solve all possible problems, whether you're currently having them or not.

For each practice you have to consider what it was designed to solve, what was the point of it to begin with? Then don't treat these practices as a checklist that must be completed every time, but follow the principles behind them.

There's a line in the movie "Dogma" that I think describes this really well. Just substitute "process" for "idea" and "Methodology" for "belief":

You can change an idea. Changing a belief is trickier. Life should be malleable and progressive; working from idea to idea permits that. Beliefs anchor you to certain points and limit growth; new ideas can't generate. Life becomes stagnant.

What conclusion would you like me to reach?

Why is it that the rest of the world has functioned fine on estimating projects of many sizes and scopes, then sticking to them; while IT screams "OH WE can't do that!"?

I'll admit a large reason is because lots of people in IT are really bad at estimating. But part of the reason we've managed to stay so bad at estimating, and the main reason all estimates seem to be so far off, is that the business side wants the estimates to be low.

The common complaint is that IT projects are "always over time and over budget". Since the IT budget (for software) is almost entirely salary, time and budget are synonymous. When you set the budget, you’ve just set the time.

But most IT projects -- and nearly every one I've worked on -- have a budget set before the detailed design is ever done. Or at least the clients have an idea in mind what they'd like it to cost. So without realizing they’re doing so, the clients set the time estimate sometimes before they’ve ever talked to the developers.

I had to help out some less-experienced people who were being asked for estimates. I told them the trick is to figure out a diplomatic way to ask, "What number would you like me to say?"

The funny thing is that this is not just being cynical, either. There's real value to it. If you're thinking four months and the client says three days, there's a good chance you don't have the same idea in mind for what you plan to do.

For instance, they ask you to write a search engine "like Google" to put on your intranet. You're thinking a couple of months. They're thinking end of the week.

It turns out they want you to buy a Google search appliance and integrate it into the intranet. To the client, "write" "create" "implement" "install" and all those other words we use that mean different things ... all mean the same thing: work that the IT guys do.

So if you want to get the work -- or if you’re an employee and have no choice in the matter -- see what number they have in mind already and tell them what they can have in that length of time. If you don't promise to deliver something in the given time frame, they'll go find someone who will. Not that they'll deliver in that time, but they'll promise to deliver in that time.

Compare this to construction. The client may get five quotes for pouring concrete. If four of the bids are close to $50k, but one of them is $20k, the client will likely assume the low bid is unrealistic and choose among the remaining contractors.

But if a programmer or independent software vendor says some work will cost $50k, the client can find someone who will promise to deliver for $20k. The sponsor will either accept the lower bid, or use it to negotiate the first vendor down to $25k. When it ends up costing $50k, that project goes in the books as "over time and over budget".

What would it look like if construction bids were awarded the same way? If for instance the client were required by law to select the lowest bid? Then contractors would low-ball every bid to get the contract. You’d end up with construction that always ran over time and over budget. You would need an endless supply of money to stay in business. You would need to be … the government.

Installing software is not worth my time

My PC is managed according to corporate standards. I can't install anything without an administrator signing on and authorizing it. I asked if I could install the software to link to my cell phone and load my contacts into it. Otherwise I'd be spending a couple of hours over the next week manually entering them all in via the keypad.

The day after I put the ticket in, someone called up and asked where the software was. I told him I had it on a CD. The local support guy came up the next morning, saw that it was an OEM disk and not some random thing I'd burned, and logged in as administrator so I could install it.

Sure, it was two days before I got what I needed, but it wasn't a compelling gotta-have-it-today issue.

Everything else on here is available as a network install, and is set up in my profile. When I get a new PC -- I'm due to be refreshed in the next month or so -- I'll go to a single application, check the boxes for everything I need, and go to lunch. When I come back, everything will be installed.

Every application that I install myself I'd have to reinstall when I get a new PC. How many hours would that take? Multiply that by the number of users in my office, which just relocated earlier this year. Most of us didn't take the hardware from the old location, we just came to blank systems at our new desks and kicked off the install process.

If I'm paying for it, it is not worth my time to install software. If my alternatives are to load all my apps on a new PC I've just bought, or to work a billable hour and pay someone else to do the installs, I'll pay the Geek Squad to click OK and reboot 14 times. Why should I expect the company I work for, who owns the PC I'm working on, to make a different decision?

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 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.

Can the FSF "Ban" Novell from selling Linux?

Novell Could Be Banned From Selling Linux: Group Claims

BOSTON - The Free Software Foundation is reviewing Novell Inc.'s right to sell new versions of Linux operating system software after the open-source community criticized Novell for teaming up with Microsoft Corp.

The problem is that the FSF wants all code to be free. Period.

That's their preference, yes.

They want to make the GPL so darned viral that no one can include any copyrighted or patented components Period.

No, they want all the components on which they hold the copyrights to be protected by those copyrights. And they want those components to be freely available to anyone who agrees to make their modifications available under the same terms.

You can't modify and distribute Microsoft's code without permission. You can't modify and distribute GPL code without permission.

The way you get permission to distribute Microsoft's code is to pay them a lot of money, or cross-license your own code. They way you get permission to distribute GPL code is to release your modifications under the GPL.

Microsoft can destroy your business model by bundling a version of what you make. GPL-using authors can destroy your business model by releasing a free version of what you make.

If you don't want to be bound by Microsoft's terms, write your own code. If you don't want to be bound by the GPL, write your own code.

How is GPL viral while Microsoft is business?

How can the FSF "ban" Novel from selling "Linux" when Linux itself is not wholely licensed under the GPL and not wholely owned by FSF? Sure, there are many GPL components within the typical Linux distro, but not all of them have to be.

According to Answers.com:

More Than a Gigabuck: Estimating GNU/Linux's Size, a 2001 study of Red Hat Linux 7.1, found that this distribution contained 30 million source lines of code. ... Slightly over half of all lines of code were licensed under the GPL. The Linux
kernel was 2.4 million lines of code, or 8% of the total.

So the first point is that no, the FSF can not ban Novell from selling a GNU/Linux-based distribution, as long as all the current license terms are followed.

However, the holder of the Linux trademark, Linux Torvalds, could choose to prohibit them from using that mark to describe what they're selling. (See Micosoft / Sun / Java™) Though I haven't seen anything suggesting he plans to do so.

Next, the Linux kernel is covered under the GPL, so even if the the FSF doesn't hold the copyright it's entirely possible the kernel authors could ask the FSF to pursue any violations on their behalf. And I suspect Stallman and Moglen would be more than happy to do so.

The bottom line, I think, is that business people who don't understand the technicalities will either see a deal with Microsoft as a reason to choose Novell for any Linux plans, or they will see the controversy as a reason to avoid Linux plans altogether. Either conclusion benefits Microsoft.

People who do understand the details will see that Novell offers them a conditional, time-limited right to use a specific version of Linux, which may or may not interoperate better with Windows systems, which can be effectively "end-of-lifed" at any time by Microsoft.

And this is bad why?

If you try hard enough, I suppose it's possible to spin anything into an attack on your pet target. But the consistency with which Neil McAllister sounds the call of doom and gloom for all things open source is really quite astonishing. Especially when you consider he writes the Open Enterprise column for Infoworld.

Take his January 29th column about the formation of the Linux Foundation for example:

On the surface, the union of Open Source Development Labs (OSDL) and the Free Standards Group (FSG) seems like a natural fit. Open standards and open source software are two great ideas that go great together.

But wouldn't it make more sense to call the merged organization the Open Source and Standards Lab, or the Free Software and Standards Group? Why did they have to go and call it the Linux Foundation?

On the one hand, it seems a shame that the group should narrow the scope of its activities to focus on a single project. Linux may be the open source poster child du jour, but it's hardly the only worthwhile project around.

If Neil had bothered to read his own magazine's newsletter the previous week, he would have known that:

With Linux now an established operating system presence for embedded, desktop and server systems, the primary evangelizing mission that the OSDL and FSG embarked upon in 2000 has come to an end, Zemlin said. The focus for the foundation going forward is on what the organization can do to help the Linux community more effectively compete with its primary operating system rival Microsoft.

The combination of the two Linux consortiums was "inevitable," said Michael Goulde, senior analyst with Forrester Research. "The challenge Linux faces is the same one Unix faced and failed -- how to become a single standard."

So what's wrong with focusing on Linux, anyway?

But then again, maybe it's not so strange -- not if you conclude that the Linux Foundation isn't any kind of philanthropic foundation at all. It's an industry trade organization, the likes of which we've seen countless times before. Judging by its charter, its true goal is little more than plain, old-fashioned corporate marketing.

As such, the Linux Foundation is a unique kind of hybrid organization, all right -- but it's not the union of open source and open standards that make it one. Rather, it stands as an example of how to combine open source with all the worst aspects of the proprietary commercial software industry. How noble.

This is really amazing. No one ever claimed that the partners in this merger were anything other than industry trade organizations, but the fact that the new foundation will continue the work of it's members is somehow un-noble. And nobility is the standard by which we should judge those who are trying to make Linux more competitive in the market.

His grammar and spelling may be better than that of the stereotypical Linux fanboys, who famously attack less-rabid supporters for their lack of purity. Or maybe he just has a better editor. But all the craft in the world doesn't disguise the fact that Neil's opinions are rarely more useful than the ramblings of an anonymous Usenet troll.