Recent conversation I had with someone the other day:

Jack: Yes, but we can’t do it like that. The business does not work that way.

Me: Why does it not work that way?

Jack: It’s a fundamental aspect of the business. We can’t change that.

Me: And I accept that, but have you thought about why it is like that?

Jack: Well because it’s not viable.

Me: Why is it not viable ?

Jack: It would cause too much havoc.

Me: Why would it cause too much havoc?

Jack: Well because the software doesn’t allow it.

Reading this script, one would think that it is quite absurd, yet this situation is quite common.

Updating a legacy system

Jack in this case was a developer, that is working on re-designing an existing system. But Jack could be anyone. In fact, many times, Jack is a user of the system.

Users are many times accustomed to having software impose the way they do their job. They have to accommodate their process to that of the way the software they are using functions. What then happens is that they become used to this way of working to the point that they actually change their process, to work with the system, many times attempting to make their own life easier.

The problem is of course that these changes have an impact on the business. At times this influences productivity, at other times revenue, or even how dealing with customers is handled, ultimately jeopardizing the business or its potential.

When the time comes to develop a new system, what was considered an impediment has now become a fundamental pillar of how the business should work. As such, the user no longer thinks of how he/she would ideally want to do his/her job and have the software adapt to that, but lets his/her requirements be driven by technology.

Of course, all this become even more vicious when new users join the scene. They are not aware of the real reasons behind certain workings and assume that that is how it is meant to be, no questions asked.

Focus on the customer, not the software

It is very important for us to analyze the true needs of our users, to make them look beyond existing systems and offer them the possibility of describing how they would want to work if they had a blank sheet of paper and could start from scratch. If we have the opportunity to re-design an existing system, let’s make sure we base it on the users needs, not the existing software.

Upgrading existing systems is not about making them use the latest, greatest and most shiny technology.

My mother wants to become a computer programmer (not to be taken literally). And guess what, she can. With all the RAD environments nowadays you really don't need to know much about the basics of programming to make applications. You can use anything you want. First step, pick an environment. You have lots to choose from (Visual Studio, Delphi, Ruby on Rails). In under 1 hour you'll have your first application working. Next step, sell it.

Now do this for about 10 years, making a profit and you can claim that you're successful in software development. You can claim you've worked for 10 years and have never had to worry about things such as polymorphism, delegation, etc.

So when someone comes along with a post talking about weird things such as SOLID or how rules are meant to be broken, you reaffirm your position as a successful developer that has never needed or understood these concepts. And since the person writing this has 1.5M visitors a month and 125K subscribers, it's OK!

(You think I'm crazy. Read some of the comments on this post).

But It's NOT OK

I don't lose sleep over what I term demoware cowboys. Everyone has a right to make a living, however way they want. I'm the first person in the room that stands up to defend not needing to graduate in CS to have a successful career in software development. However, I also defend studying, understanding and practicing software engineering, and to continuously improve yourself. Just because you sell software and put food on the table doesn't mean you've accomplished all there is to in your field.

What does bother me however is people talking about things without truly understanding them. It's important to act with responsibility, specially when having so many followers.

Some of us write software for a living, as opposed to just writing about it,  and it's not only about getting the job done.

I read a post today about how there should be a plug-in for Visual Studio to disable copy/paste, in order to prevent people from copying and pasting the same code over and over again, instead of applying basic design principles (DRY). Now I'm sure the author didn't mean this in a serious way (it's hell to be without copy/paste, and if you don't believe me, use the iPhone for a couple of days), but it reminds me of recent discussions about RhinoMock vs TypeMock, or put another way, TypeMock vs every other mocking framework out there.

The main discussion was that TypeMock could lead to malpractice. By using TypeMock, people could potentially end up with tightly coupled code. Since there isn't a need to inject dependencies, you could create dependent objects in your classes. I posted my thoughts on this a long time ago (too far back for Live Writer to show it up in recent blog posts), so I'm not going to get into too much detail, but suffice to say, I didn't agree then and I still don't agree now.

But what has that got to do with the copy/paste post you might be asking yourself. Well I think in both cases, we are showing signs of wanting the tool/framework to do the work for us, to police us, so to speak. Which begs the question, why?

I work on a team, as a tech lead. The part about work is questionable, but nonetheless I am on a team. Part of my job is to oversee my team and make sure that things are being done correctly. In my book, correct means applying good design principles. It is my job to make sure that my team applies these principles. If a team member is new or is not familiar with certain concepts, it's my job to teach them to him/her. With new team members, there is normally a period of code-review, where during check-ins code is reviewed by senior developers (either myself or someone else on the team) to make sure that they comply not only with design principles but standards of coding and practices. However, as time elapses, code reviews become less frequent (although there should always be peer review on a team from time to time). So initially it might be a time-consuming job, but in the long run it isn't. In many cases it's also very productive since there's always something new you can learn.

If people are taught things in a way, that not only do they understand, but see what happens when they do it the wrong way, they will act correctly.

Developers are not stupid.

I was just reading on a blog a reference to an article Michael Swindell published about native application development. It's fair to say that you don't always have to agree with everything someone writes, but I think in this particular case, there is misleading information.

The story of the .NET framework lagging behind native performance just doesn't cut it anymore. Wake up and smell the coffee. We are three versions into the .NET framework and Microsoft is already talking about 4.0. While we are seeing new things that will make applications and architectures more flexible and easier to maintain (such as dynamic binding), Delphi developers are still complaining about the garbage collector.

This might come as a shock to you, but in a business application, your end customer is not going to know how long it took him to destroy that order object, or to create it for that matter. He cares about his application. He cares about interoperability. He cares about his ROI. With all that the .NET Framework (or Java for that matter) has to offer in terms of productivity to the programmer, with all the frameworks that exists to make application development easier to maintain, the native vs interpreted performance argument doesn't stand anymore.

I'm not saying that native is bad, far from it. Right now, and for the foreseeable future, there is a place for native code, just as the article points out, something needs to be under that virtual machine or the RIA. Until all computer systems (excluding my mother, she's already on .NET 3.5) have the .NET framework installed, there will be room for small utilities to run natively. But enterprise level or businesses do not have an issue with making use of applications that use the .NET framework. They don't have an issue with deployment. You can still automate and accomplish easy deployment with .NET (and I'm not even talking about ClickOnce).

Every day we have faster processors coming out, we have cheaper memory and yet 6 years after the release of .NET we are still clinging on how native out-performs managed. They say you shouldn't dismiss something without having really tried it. Unfortunately that's something I see a lot in the Delphi community.