Yes, this is another challenge that I ran into which I consider well suited for an interview.

• It is short
• It doesn't require specific knowledge
• There are a lot of ways of solving that
• I can give the develop access to Google and the test is still valid

The test itself is very simple:

• Detect if another instance of the application is running on the network which is registered to the same user
• It doesn't have to be hack proof, and it doesn't have to be 100% complete. The purpose it to stop casual copying, not serious hackers.
• A great example of the feature in action is R# detecting that two users are using the same license at the same time.

Oh, and for real world scenarios, use a licensing framework instead of rolling your own.

Recently there has been a lot of discussion about how we can make development easier. It usually started with someone stating "X is too hard, we must make X approachable to the masses".

My response to that was:

You get what you pay for, deal with it.

It was considered rude, which wasn't my intention, but that is beside the point.

One of the things that I just can't understand is the assumption that development is a non skilled labor. That you can just get a bunch of apes from the zoo and crack the whip until the project is done.

Sorry, it just doesn't work like this.

Development requires a lot of skill, it requires quite a lot of knowledge and at least some measure of affinity. It takes time and effort to be a good developer. You won't be a good developer if you seek the "X in 24 Hours" or "Y in 21 days". Those things only barely scratch the surface, and that is not going to help at all for real problems.

And yes, a lot of the people who call themselves developers should put down their keyboards and go home.

I don't think that we need to apologize if we are working at a high level that makes it hard to beginners. Coming back to the idea that this is not something that you can just pick up.

And yes, experience matters. And no, one years repeated fifteen times does not count.

Learn programming in 10 years is a good read, which I recommend. But the underlying premise is that there is quite a lot of theory and practical experience underlying what we are doing on a day to day basis. If you don't get that, you are out of the game.

I refuse to be ashamed of requiring people to understand advanced concepts. That is what their job is all about.

This is something that has been making the rounds lately. Just about any developer that have seen it was greatly amused.

Check out the video.

This is so good, I intend to make this into a part of several of my presentations.

Adi has posted a post that I am not in agreement with: there are some things a good developer is NOT required to know.

[Quoting Jeff Atwood and Peter Norvig] Know how long it takes your computer to execute an instruction, fetch a word from memory (with and without a cache miss), read consecutive words from disk, and seek to a new location on disk

I did learn these things, but after reading Jeff's post I have been trying to remember a project I worked on during the past 10 years which required this type of knowledge - and I got nothing.

Well, I used knowledge about reading & seeking to / from disks the last two weeks. They are extremely important when you are thinking about high perf large I/O. Fetching words from memory, and the implications of ensuring good locality have huge affects on the type of performance that you are getting to get. As a simple example, a large part of the reason that thread switching is slow is that the CPU cache is mostly misses when you switch a thread.

You should know those things, and you should know how to apply them. No, they don't come often, and I can think of a lot more things that I would like a developer to know (OO, to start with) more than those low level details, but those are important to know.

Ryan Lanciaux has tagged me, so I guess I really don't have a choice

How old were you when you first started programming?

Depending on how you define programming, I remember playing with Logo and that annoying turtle at 8 or 9, using a machine that was old for the time, and using floppies that where about 30 cm square (never seen them before or after).

How did you get started in programming?

I was bored and programming was a way to do stuff with the computer that didn't required being online. At the time, being online cost a fortune, so I really had to limit myself, programming helped. Thinking back, I burned a lot of hours on trying to figure this out.

What was your first language?

Probably BASIC or Pascal, if you want to discount Logo. I remember being very frustrated with programming, because I hit a ceiling in my understanding of programming, and I wasn't not able to go over it. Throughout high school, I was simply unable to understand dynamic memory allocation. After high school I took a course at C & C++, and then it was: "Oh, of course, it makes a lot of sense".

What was the first real program you wrote?

Hm, good question. The first that I would define as an Application, rather than just a bunch of code was an online forum, then still called BBS (although it run on http). I had a lot of fun building that, but thinking back, it was scary.

What languages have you used since you started programming?

Another complex question. What is used?

Written applications at: C#, obviously, VB3,4 and 6, C and C++, PHP. Perl.

By that standard, I never used VB.Net, but I wouldn't say that I don't know it.

What was your first professional programming gig?

Writing a website for a printing company. The pay was lousy, but the job was a dream. I was getting paid to play around in the computer, heaven!

If you knew then what you know now, would you have started programming?

Yes, no question about that.

If there is one thing you learned along the way that you would tell new developers, what would it be?

If you didn't get it to fail, you haven't done anything. The only way to learn is to fail, and after it has failed, fix it.

Oh, and read the bloody error message.

What's the most fun you've ever had programming?

Writing Rhino Mocks, I would say. That was a purely intellectual exercise at the time, but it was a lot of fun coming up with the design and making it work. I remember capturing two of my soldiers and having a do a design review. None of them was a programmer, or a technical person by any means, but it was very useful. I was teased about that for years :-)

Casey had this to say:

I have actually seen organisations where (in one case actually explicitly expressed, and in many where it wasn't spoken out loud) software delivered roughly meeting the requirements on how the UI worked was considered delivered. The work to make it work (usually way more work than the initial delivery) was considered 'bug fixing' and therefore was billable additinally by the IT department or outsourcer.

Which reminded me of a joke about consultants, no relation to anyone I know, etc...

One day the manager calls the consultant to talk about the time sheet report...

Manager: You charged us on Wednesday for 19 hours, but you were here for only about 9 hours on Wednesday.

Consultant: Well, of course. Look, it is very detailed. I was here from 9:00 to 18:00, right?

Manager: Right.

Consultant: And because we left without a good solution, I kept thinking about it in the car, and when I walked the dog. You see, it is the entries for 18:00 - 19:30 and 20:00 - 20:45. From 19:30 - 20:00 I had dinner, I didn't charge you for that.

Manager: Nice of you. And the other 8 hours? 22:00 - 06:00 ?

Consultant: Well,when I walked the dog, I finally had a vision, everything came together in a moment of brilliance, and I could see the solution in my head. All I had to do is connect some little pieces and it would work.

Manager: Oh, so you did an all nighter?

Consultant: Ha? Of course not. I went home thinking about the idea, and then I went to bed and slept on it for 8 hours.

The above is not my modus operandi, nor am I willing to work with those who does.  This is relevant because I am not going to consider practices built in those kind of shops as important to most of the discussion about software development.

All that aside, how the hell do you get the client to agree to pay for bug fixes? All my contracts include a 6 months guarantee for bug fixing, and most of the time they also include SLAs that says "drop whatever and get there", which is annoying as hell when this happened*. This means that I can't bill someone for bug fixes (change request are another matter, but those are for another time**), which is a great incentive to not have bugs.

* At one time I was called, after being on the phone for about an hour, came to the client, sat for 5 minute, sent a death treat to the DBA, and left. No space on the DB hard disk, argh! They backed it to the same HD and never cleaned it up.

** "Oh, you wanted it to also work? That wasn't in the original spec..." doesn't really fly in the real world

While there is value in the item on the right, I value the item on the left more.

This is in response to a comment by Jdn, I started to comment in reply, and then I reconsidered, this is much more important. A bit of background. Karthik has commented that "Unfortunately too often many software managers fall into the trap of thinking that developers are "plug and play" in a project and assume they can be added/removed as needed." and proceeded with some discussion on why this is and how it can be avoided.

I responded to that by saying that I wouldn't really wish to work with or for such a place, to be precise, here is what I said:

I would assert that any place that treats their employee in such a fashion is not a place that I would like to work for or with.
When I was in the army, the _ultimate_ place for plug & play mentality, there was a significant emphasis on making soldiers happy, and a true understanding of what it was to have a good soldier serving with you. Those are rare, and people fight over them.
To suggest that you can replace one person with another, even given they have the same training is ludicrous

From personal experience, when I was the Executive Officer of the prison, the prison Commander has shamelessly stole my best man when I was away at a course, causing quite a problem for me (unfortunately not something that you can just plug & play). That hurt, and it took about six months to get someone to do the job right, and even then, the guy wasn't on the same level. (And yes, this had nothing to do with computers, programming, or the like.)

Now, to Jdn's comment:

In a perverse way, I can see, from the perspective of a business, why having good/great developers, who bring in advanced programming techniques, can be a business risk.
[...snip...] you have to view all employees as being replaceable, because the good/great ones will always have better opportunities (even if they are not actively looking), and turnover for whatever reason is the norm not the exception.
Suppose you are a business with an established software 'inventory', and suppose it isn't the greatest in the world. But it gets the job done, more or less. Suppose an Ayende-level developer comes in and wants to change things.  We already know he is a risk because he says things like:
"not a place that I would like to work for or with."

If you view me as replaceable, I will certainly have an incentive to moving to somewhere where I wouldn't be just another code monkey. Bad code bothers me, I try to fix that, but that is rarely a reason to change a workplace. I like challenges. And there are few things more interesting than a colleague's face after a masterfully done shift+delete combination.
What I meant with that is that I wouldn't want to work for a place that thought of me and my co-workers as cogs in a machine, to be purchased by the dozen and treated as expendable.

You know what the most effective way to get good people? Treating them well, appreciating their work and making them happy. If a person like what they are doing, and they like where they are doing it, there would need to be a serious incentive to moving away. A good manager will ensure that they are getting good people, and they will ensure that they will keep them. That is their job.

Mediocre code that can be maintained by a wider pool of developers is in a certain respect more valuable to a business than having great code that can only be maintained by a significantly smaller subset of developers.

At a greater cost over the life time of the project. If you want to speak in numbers the MBAs will understand, you are going to have far higher TCO because you refuse to make the initial investment.

To quote Mark Miller, you can get more done, faster, if you have good initial architecture and overall better approach to software.

Jdn's concludes with a good approach:

I'm offering services for clients.  I can't disrupt their business because I don't think their code is pretty enough.
What I can do better, going forward, is learn to make the incremental changes that gets them on their way to prettier code.  My attitude is *not* "well, I can't do anything so I won't even try."
But at the end of the day, I have to do what is best for the *client*.  If that means typed datasets (picking on them, but include anything you personally cringe over), then I can partial class and override to make them better, but typed datasets it will be.

I would probably be more radical about the way that I would go about it, but the general approach is very similar, especially when you have an existing code base or architecture in place.

Jdn has a good post that I recommend that you read about Novices, Sheep and Morts.

My feeling about designers, etc is that they are most certainly no inherently bad, they can be extremely valuable to get me someplace quickly. I do think that a lot of the designers, etc in use today are bad, because they produce unmaintainable code. Hell, WCF proxy generator is a good example of one, it doesn't recognize the common binding settings, always producing custom binding. It is much easier from the developer point of view, much harder from the user point of view.

My objection is for dumbed-down tools, not for the existence of the tools. I don't think that it is a good business decision to make use of those for anything but a demo, and I believe that I can, with the use of good framework and maintainable practices, get faster velocity than anyone using the wizards for most kinds of applications. This include the forms over data approach, by the way. <% EditForm(Table: Customers) %> is faster than doing dragging a table to the page.

A *large* number of applications have a clear set of requirements, and they won't be extended in the future.  You need to handle the requirements that the business users require right now.

If an application takes less than a man month to write, you are going to need to maintain it, simply because it is not sustainable to keep adding features to such an application without changing things. Doing it in a way that help maintenance is valuable, even if the application is not going to be significantly extended later on. Fixing bugs, working with the code, etc are all much easier when you write with maintainability in mind. And it is not as if maintainability is some painful tax that you have suddenly acquired, it is simply what happens when you write good code.

And it is *unarguable* that it is easier to use, say, the ObjectDataSource, to accomplish this than to do MVP/MPC.  There is *no* argument against this.  None. 

Ha? I would certainly argue that. Just try doing anything remotely interesting with the ODS and you will see my point. The ODS is just a way to call a method to get a data source, and it has such wonder methods that pass me IDictionary of parameters, and expect me to do something with it. That may be good for tabular data, but I don't have that.

It is unarguably easier to use a wizard or designer to design the vast majority of applications that are used by businesses around the world. 

Again, I would certainly argue that. Because you ignore the part that happens after you generated the grid or the form, where you now need to do all the tweaks that the client want (debt rows should be yellow, big debt rows should be red, late returns are marked with an icon, give me row level security and column level filtering, etc).

The code that is produced by using designers, wizards, etc. is more easily maintained by people who aren't alpha-geeks.

Here is something that I can't really understand. If alpha geeks can't maintain this code, why would others be able to do so? Unmaintainable is just it. And I have worked on creative solutions to a lot of technical problems that stemmed from the fact that I wanted to do it the RAD way, and have came to regret it.

Jeff Atwood is talking about why background compilation is part of a culture of code monkeys and that we should accept it and get on with the program:

One of the problems with the army of monkeys approach that everyone seems to ignore is that treating someone like a monkey will get you monkey-like responses. We have a problem of escelating complexity in software, and trying to solve it by serregating the problems to the "Smart Dudes" and the "Monkeys" is not really helping. We are not writing Hello World applications any more.

I had the chance to try to port a monkey's code from one langauge to the other, and I couldn't make sense of it. You can imagine at what stage I had to throw up my hands and seek that monkey out to have it explain to me what the hell is going on in the code. It was 2 months old code, and the monkey couldn't do it. The magic numbers in the code were what the monkey was told to write, the logic constructs in the code were what the monkey was told to write. The bugs were the monkey's own fault, I assume, but it may very well be the case that the monkey was instructed to put them in as well.

Trying to get a good product out of an army of monkeys requires constant policing, lest they do something stupid. Software is such a complex beast that have a monkey anywhere in the process will put a serious risk to the project at large. Some of the stuff that I have seen:

• Using a public static bool g_IsUserAuthenticated;
• Subscribing each page to a global & static event handler.
• String concentration for query building (using the safeForSQL() method, of course)
• The single user only web applications
• For more references, check the Daily WTF

Each of those share a single trait, this is a single stupid thing that had a drastic affect on the entire application.

In the case of the static event handler, it took about two days to see the effects properly, at which point the application crushed with OOM errors. That was fun to find out.

Armies of monkeys simply doesn't scale, a monkey can't handle complexity well, so you end up dumbing the environment to the level of the monkey, therefor, you are reducing your ability to make any sort of change and maintainability is a nightmare.

So, Jeff, I do agree with you that there is this cult of monkeys, I do not agree that we should agree to this.

See the full post.

(Via Hammet)