Jeremy Millier is brining up a pain point to me here. I see quite a lot of people who treat developers as data entry guys for the Architect perfect design. It gets to the point where people argue with me (vehemently) that this or that features should abosuletly be removed, because it is too complex for Darl, their developer stero-type.

It doesn't take much to move away from the Darl arch-type. But is seems to me that this is something that a lot of business do not want or not willing to change. On the contrary, they would like to get more of them, and then they get tools that have "No Code Required" stamp on them, and expect to get results.

I have a junior developer working with me at the moment, my biggest pain point with him? He isn't lazy enough. It is something that I am working at right now, making sure that he will understand that Lazy is Good(TM).

Yesterday I spent two hours pairing with another developer, going over everything that we needed to setup the current project. This meant that I had went over the build process target by target, explaining its use, and showing how to deploy, we created a new project and setup everything from a database to the configuration file so we could get build the [ActiveRecord] class and going over the various database inheritance implementation scenarios and what the trade-offs.

The easiest way to work with good developers is to invest in them and help them grow.

Rocky Lhotka paints a grim picture of our industry 20 years from now:

As you can probably guess from the title, I don't agree. Rocky makes a good point, but I simply do not agree with his prediction.

I have not a clue about how SQL Server Tabular Data Stream work, nor do I have any interest in it. That doesn't mean that I need to find a SQL guru to do my databases. Or understand what goes on the bus when I am drawing an image using GDI+. The whole point of abstracting away the underlying layers is to let me focus on doing what I want without getting distracted by the implementation details.

I am one of those that like to have a good understanding on what is going on under the hood, mainly because I am also one of those that keep running into problems because of this stuff. Nevertheless, quite a bit of it Just Works. And unlike the medical field, which is what Rocky compare the devs into (at least it is not construction again :-)), we can move into new areas relatively safely.

There is a place for specialists, certainly. If my database is running slow, and I can't figure out why, I'll call up a SQL guru to point out where I am being stupid. But, that is not something that I would need on a general basis. I expect developers to know a lot, about a wide variety of subjects, but I don't expect them to be experts in all those fields. They need to have a good understanding of what they are doing in any field they are going to spend significant amount of time on, and they should definately have at least one or two areas of expertise where they excel.

I expect to see a lot more work going into building non leaky abstractions in the future, and I think that we are getting better and better at it. Furthermore, I believe we will see a lot more emphasis on Not Surprising The Developer. I fully expect being able to get a new framework, read the overall idea and be productive in a matter of a day or two. If I am not, then the fault is with the framework, period. This means good naming convention, discoverability and googlability, among other important attributes.

In short, technology scale better than people, so I expect technology to fill the gaps. The alternative that Rocky suggest doesn't hold water, in my opinion. If I need to hire a whole bunch of consultants at 250$/hour just to get a BuzzwardTechnology working for my forms over data scenario, I'll simply stick with what I have now. BuzzwardTechnology be damned!

Technology doesn't exists for the sake of technology alone, it exists to answer some sort of a business need, and if it can't handle that, it wouldn't succeed. Handling that, by defination, means that I can get my money's value back.

But still start using it now. Another reply to Adi, this time a new post in which he clarifies what he meant before. The main idea is that Microsoft's products get a big mindshare regardless of their relative qualities. I do not doubt that this is true, a lot of people goes for Microsoft because it is Microsoft. Expecting that this will pay off in the future is still the wrong thing to do.

I am one of those that would move to a new technology just because it gives me a tiny bit more, if it preserves everything that I can do in my current technologies. I am now using MsBuild in favor of Nant, because I can get the build script and the VS project to match (and yes, I know I can call msbuild from Nant). I moved to NUnit from MbUnit and back again, for much the same reasons.

But if it doesn't improve, why bother?  Adi brings up a couple of examples:

I will refuse to use MS Test until:

• It has a performance on par with NUnit/MbUnit - currently aroudn 30% slower, clock time.
• It support the very basic of test patterns, Abstract Test Class.
• It can be run as part of the build without jumping through hops.

There are people that would use MS Test instead of using NUnit, I am sure, although you don't here about it almost at all. They make compromises because they are using Microsoft, compromises that I am not willing to make.

Linq is an extention to the language, not a technology. Assuming that Adi is talking about one of the ORM technologies from Microsoft, I do not think that I can argue that this is the case, only that I do not think that this is something that is done with planning and foresight. Just to point out, no one answered to my Linq challange yet, and I have no idea if this is even possible.

I started doing C# when I was mostly building Windows applications. The only good story at the time was VB or C++. If you wanted to use Java you could, if you really liked laying stuff out in code, and then running it to see what you wanted. Java was never very strong on the client. C# came to replace a market that was dying for a replacement, which is why it caught such a big audiance in such a short time. If Sun had its act together in 95-00, it could have made Java the prevasive technology everywhere.

I would really love to compete on a technology level with someone that is buying completely into this approach. I can do better than most of the market by using the best tools for the job. Limiting myself to Microsoft tools is limiting myself to the level that Microsoft believes most programmers should be.

I once had to resort to runtime code generation in order to sort a grid view. It is complex, yes, but it meant that I had sorting working for all the grids in the application, for the cost of half a day, while the upstream team wrote custom code per grid per page, because that is how they were told it should work.

Going with MS related technology blindly is not a good thing at all. It is not a strategy, it is herd thinking. It is the old argument about: "No one was fired for choosing Microsoft".

Bill is asking how he can improve the work process of his team. The worst thing in his tale (aside from 1,500 lines of code in a set accessor!) is that there isn't somebody that is in charge for the team, at least not someone who is technical. Unless a person is in a position of authority (preferably well established, rather than ad-hoc one), making significant changes is difficult.

I get a lot of milage from giving the client a link to the continious integration machine. They check to see what progress we made routinely, and the most common request I hear from them is to make the CI build more stable. (The answer to that is to give me a staging machine, but that is another story).

Doing something like this can prove to the stake holders that it is possibl deliver something that they desire, therefor, they will back the requirements when demands are made. In this situations, hiring the boss can be an interesting approach, go look for someone that you really admire, and then convince them to come work as the team leader /architect. Other ways include bringing in a coach, or sending the team to training.

All of the above assume that there is some sort of backup from above. If this is not possible, then support from the team members is crucial. From Bill's post, it doesn't sound like the other members of the teams are interested, but this may be because it wasn't presented in the right manner. It is very easy to give advice about people I never knew, but broadly:

• Show Mort how he can be more productive using smarter tools
• Pair with Jade to get stuff done.
• Challange the Primadona to a duel at sunrise.

More seriously, since Jade is apperantly the most experiance guy in Bill's shop, a good way to start would be to sit with him and try to work incremental improvements. "For the next month, we are putting in continious integration system, month after that, we start working on our design debt, etc". Define a certain level of quality that you will not go beneath. When two developers are collaborating, it should be easier to guide Mort into the fold. To begin with, the Primadona can be ignored, but once stuff started to roll, and the Primadona breaks it, take his code out out. I have reverted changes that broke unit tests in the past, much to the angst of a developer who didn't consider what would happen when I come in to a broken build with no idea what had happened.

Failing all of that, starting to carry a 5Kg hammer and speaking softly always worked for me.

Bill also mentions:

Bill, if you are really serious about that, get another job. To start with, you will need to educate the rest of the team about what is happening. They need to be able to go to your code and understand what is going on. If you aren't talking at the same level, this is a problem. And you are the guy to fix it.

But they still want cutting edge results...

Adi had posted about my recent series of posts about getting the best tools for the job.

Guilty as charged about the suggested. I argued that that we can get better productivity and higher quality, at the cost of having to train developers that we pick off the street. Adi think that I am overlooking the cost here:

I would like to refer to this post for backup. There is a tremendous amount of effort already invested in the tools. This means that I wouldn't have to build it myself in order to get the functionality that I need. Hell, something as simple* as MonoRail's [DataBind] can drastically reduce the amount of code that you need to write and maintain.

At the end, the job has to be done, and insisting on trying to do it via custom code is simply NIH. There are cases where I say that whatever exists out there is not going to work for this scenario, and I roll everything from scratch, but to get to the point where the official policy is "either Microsoft or hand-written stuff, nothing else" - which was an actual statement made by a client to me is a long shot.

About training, I do not think that it is too much to invest three days to a week in giving a new guy a chance to learn all the stuff that you are using. I had to bring in three new developers into my projects, none of them had any previous encounters with any of the technologies that we are using. All became productive in a very short time, one of them is exteremely annoying in managing to find the wierdest corner cases in NHibernate. They are all good developers, but I never even thought to ask them about whatever they knew about any of the stuff that we were using.

As an aside, I keep talking about the first steps of interviews, because I stop so many interviews there, but one of the things that I do in an interview is find out what the candidate doesn't know, and have them write something trivial with that technology. For instance, one candidate didn't know GDI, so I asked him to draw a line on the screen.

One of the worst candidates that I interviewed was someone that actually had NHibernate experiance, he was one of those that could not reverse a string...

* Simple is defined in terms of usage, not implementation, the data binder is certainly not simple.

This is a reply to Eli's IoC and Average Programmers.

Just to clarify:

• Coding to the Mort's level will get you bad code, period. I deal with big applications, which means that I have zero use of demo-ware features. Trying to force an application to use them "because the programmer can use the designer to do all the work" is a stupid. It creates more work, it add more complexity and it results in hard to maintain code.
• Not investing in developers is stupid, period. Right now We! are hiring. I get to interview a lot of people, and the bar to get hired is not with knowledge. I can teach knowledge, and I can mentor beginners. It is fully expected that you would have a learning curve. Trying to avoid that by mandating stupid code means that you will not be able to keep good people, and those that you keep will not like what they are doing...

That said, there is such a thing as Too Much Magic. But it isn't at the Mort's level.

Update: this looks relevant - Technical Debt

I got a couple of comments on my previous post about code quality and developers quality, where clients demand lower quality code. Basically, "that is the way it is".

I don't argue that this is happening, I had to butt head against to approach before, and I can sort of understand the arguments from the business side. The problem is that the approach is flawed.

I get to see quite a bit of average code (By my standards, average doesn't mean bad). It is usually straightforward code, sometimes it does more than it needs, but in general, it is not a problem to understand what is going on. The problem with average code is that it usually much harder to handle change.

It is hard to change because the code needs to do a lot more than it would have done had it been using a smarter approach. I find that it is much easier to train developers to use better tools and approaches than to lower the level of the code to the level of the programmers. Most developers would like to learn new stuff, not work on the same rusty codebase.

The end result, from the business perspective, is a higher quality product that was delivered faster, costed less, and whose maintainace costs are significantly lower. Of course, this necessitate investing in the developers, and that comes out of the IT budget. The cost of projects comes from someone else's budget.

Daniel is asking several good questions about experstise. Here are my answers:

1. Is it possible to be passionate without being a zealot?
   Hm, I certainly hope so. I am passionate about many subjects, but I think that I am still able to listen to the other side and have a reasonable discussion.
2. If someone came up with something better than the .net framework, would you switch?
   This is a really tough question. It would have to be something with an order of magnitude improvement over .Net, something like the switch from C++ to C#, in order to make me consider it for most of my activities. Right now, I don't see it coming.
   Beyond that, there is a big issue with abandoning knowledge. I know a lot about .Net, from how to do dynamic code generation to why you are allowed to do double locking to what is happening when you specify RegexOption.Compiled. I can read a stack trace and usually pinpoint the problem with ease. I wouldn't be able to do that in another technology for a long time, and that is an important part of what makes me effective developer, that I know my environment. I'm not talking about just the API, I am talking that I am comportable editing msbuild / nant files, and that I have extensive knowledge of keyboard shortcuts, that I know how fusion loads an assembly, and how I can interfer with that. I can fuzz around with the internals of ASP.Net and AppDomain load issues with confidence.
   Getting anywhere near this level of confidence is not something that is just going to happened.
   There is a reason why I don't label myself as Java / C++ guy. I know both language reasonably well. And I have a lot of experiance
3. How much of your identity is bound to being a .net programmer?
   Moo. The question cannot be answered within the given parameters. (I actually has an exception message that throws this.)
   My identity has nothing to do to being a .net programmer. I am a developer that happens to be working on .Net. If I were to make a different decision several years ago you would have probably seen quite a lot of posts here about log4j and Hibernate, praising IntelliJ and writing Groovy DSL for Spring configurations :-)

This is a great list. Rob manages to score with each and every point. (Check the rest of the posts as well, it is interesting, although I strongly disagree with some of the stuff that he is saying).

What really interested me was point 7, "Building Something That Matters". Rob gives several examples, all of them different. I got a system in production that moves money around, it doesn't really matters to me. Being able to use NQG's queries does.

What excites you as a developer?