First, I seem to recall writing an article on this subject before, probably on one of my other blogs. Second, this is geared more toward CTOs, CEOs, and business owners who may not be as familiar with computer science as people with computer science degrees.
There is this concept in industry of a "house programming language." This comes about mostly from CTOs or CEOs who want to simplify their business but who do not understand programming very well. There are numerous justifications for doing this, and they generally have completely valid justifications, but the justifications do not apply well to software development.
A "house programming language" is the programming language used within a company, to the exclusion of any other language. It is generally a language that is equally good for most tasks. In fact, it is generally Java, though it might be more appropriate to say that Java is equally bad for most tasks.
The justifications for a "house programming language" may include simplicity, avoidance of training costs, lower hiring costs, and avoiding problems when the only employee who know a language quits. These are all valid, in certain contexts. Unfortunately, most of these contexts are either completely invalid when applied to software development, or they only apply to very specific circumstances.
Simplicity when running a business can provide many potential benefits, but in software development, using a language that is a poor fit for a task can cause far more complexity than it is worth. It is important to think of simplicity beyond just what language is used. A language that is poorly suited to a task can cost far more money in man-hours than a more suitable language. A program written in a poorly suited language can be so much more complex that it is difficult or even impossible to maintain. Instead of thinking in terms of avoiding using more products than absolutely necessary, think in terms of the bottom line. Businesses can benefit from simplicity, but when simplicity costs far more than complexity, the choice should be obvious.
Avoidance of training costs is certainly worth considering. Of course, if this was really a problem, why are most businesses using MS Office instead of LibreOffice? Honestly, this sounds more like an excuse than anything, but it still deserves some attention. First, any decent programmer should be able to learn pretty much any programming language without too much effort. That said, do not expect employees to be able to find learning resources for obsolete languages, and it might be worth a second thought if an employee is recommending a language with a significantly different programming paradigm than your typical languages. I hate to say it, but if an employee is recommending a functional language, it might be a good idea to take a step back and seriously consider the implications. Keep in mind that I am a big proponent of functional programming, and I will assert that learning functional programming will almost always make a programmer better. That said, if your company is fairly small, and you cannot spare a bit of work for a week or so, perhaps it would be better to hold off. Otherwise though, if your employees cannot learn a new programming language without costing you a significant amount of money, you are already in trouble. If you cannot get anyone better for what you are offering, then you are really in trouble. You should already know this, but you get what you pay for. Software developers are not cheap, and if you won't pay enough to get quality software developers, you will get what you deserve.
That brings us to hiring costs. This should be fairly straight forward. If you can only afford to hire developers who only know Java, then you probably cannot afford to succeed in business. Yes, developers who only know Java are almost always cheaper than people who actually have degrees in computer science. Read that again if you didn't get it the first time. There is a lot more to programming than just knowing one programming language. A degree in computer science, software engineering, or anything else related requires learning an essential software development skill: problem solving. Anyone can write code. Finding the best solution to a problem is way more difficult than just writing some code. Again, you get what you pay for. If you make your company a "Java house," just so you can hire cheap, one-language-wonders without any real experience or training, you will also get what you deserve.
So, what if the only person in the company that knows the language used to write this important program quits, is fired, or even dies? Honestly, I cannot say I have any sympathy for you. If this is on your list of excuses for wanting a "house language," you clearly recognize that this is a risk. If you realize that this is a risk, instead of forcing your one decent employee to write the program in a poorly suited language, why not have that employee teach someone else that language, or even have a few other employees learn that language themselves? If they are decent software developers, this should not be such a difficult task, and it will improve the overall quality of those employees. A few times, I have heard a more dramatic version of this problem. What if your other employees won't learn that language? This is a business problem, not a simplicity or programming problem. If you were a manager at McDonald's, and you told an employee to go learn to make a new sandwich, would you stop carrying that sandwich, because no one was willing to learn to make it? I hope you would fire that employee. Now, if you would fire an employee getting paid minimum wage over a refusal to do necessary work, why would you ever accept that kind of behavior from a salaried employee getting paid far more? Anyhow, like I said, this is a business problem. A McDonald's restaurant does not have just one employee that knows how to make a particular sandwich, take orders from drive through, or really anything else. If you cannot manage your employees better than McDonald's... Yeah well, like I keep saying, you get what you deserve.
To manage software developers, you need to understand some things about software development and programming languages. I am going to try to make this easy, by distilling out just the information relevant to a CEO or CTO that is not very familiar with software development.
To start with, programming languages are not one size fits all tools. Yes, many programmers have favorite languages, but the choice of language should never be entirely based on personal preference (there are programmers that do this; you don't want them working for you). Programming languages are tools. Just like construction tools, some are better for some tasks than others. You may have seen someone use a wrench or screwdriver to pound in a nail, in a pinch. This does not mean it would be appropriate for a building contractor to only provide his or her employees with a wrench. Imagine building a house, using the side of a wrench to pound in every nail. Now, think about programming languages in the same terms. A person might prefer a wrench for most tasks, just like most programmers have a language they prefer over most others. That does not mean that it is a good idea to force them to screw in every screw and pound in every nail with a wrench. Likewise, it is not a good idea to force a programmer to use the same language for everything. Using a wrench to turn screws and pound nails will take far longer and result in damage to the fasteners and whatever they are holding together. Using a language poorly suited to a task will result in shoddy, buggy software that is extremely difficult to maintain, and if you forced the programmers to use that language, the poor quality is your fault! Don't be that guy.
Second, good programmers can learn new languages easily. Programming is a funny thing. Once a programmer has learned one language, it gets easier to learn the next (just like spoken languages, actually). Most popular languages are based on the same paradigm. There are really only two language paradigms used in industry: Imperative programming and functional programming. There are a few other paradigms, but they are mostly academic. Imperative programming is, by far, the most common. Once a programmer has learned an imperative language, that programmer should understand the concepts of programming well enough that learning another imperative language is fairly easy. If he or she cannot do this, you have a choice: retrain the employee, fire the employee, or let the employee keep costing your business. A person that does not understand the concepts of programming well enough to learn a new language fairly easily is not a programmer and should not be employed as a programmer. Now, there is also the question of, what if one employee suggests using a functional language. We will discuss that next.
Third, learning new programming languages is good for your employees. I mean this in several ways. Knowing more programming languages is good, because it makes a software developer more valuable and more hireable. If you are in the habit of underpaying your employees, you may view this as a bad thing. In this case, shame on you. Otherwise, though, there are some additional benefit that you will benefit from as well. Learning a new programming language generally changes how a person thinks about programming. Every language is different, and these differences often help teach a programmer something new about programming and how to think about solving a problem. In other words, learning a new language often improves a person's problem solving skills, which are really the most important skills for a software developer. Improving the problem solving skills of your programmers will almost certainly benefit you. Now, learning a new programming paradigm is many times better for this. Learning functional programming requires thinking totally differently about programming and problem solving. This tends to make it harder and more time consuming, but at the same time, the improvement in problem solving skills is equally dramatic. If your company can afford the time required for some software developers to learn one or two functional languages, it will almost certainly be worth it.
Fourth, knowing more programming languages makes your employee more valuable to you. I said programming languages are tools, and they are. Imagine hiring a construction worker that only knows how to use a hammer. He does not know how to use a screwdriver, a wrench, a drill, or anything else. He only knows how to use a hammer. How much more valuable would this employee be if you trained him to use a screwdriver? And what about a drill, and then maybe the wrench? This applies equally to programmers. Maybe you do hire someone who only knows Java. If you make sure that employee learns a few more languages, you will have an employee that can do that much more for your company. An employee who can write a web application in Java is nice, but if that employee also knows Erlang, NodeJS JavaScript, and Python, you have someone who can pick the best tool for the job from a selection that covers a broad range of applications. Haskell is a great language for analytics. Python is great when you need a fairly lightweight application very quickly (it is also an excellent desk calculator). Erlang is awesome for concurrent server applications. NodeJS is very good when you need a low processor usage web service with a lot of community language support. C or C++ is good when performance is essential. Java is not very good for any of these things, and some of these things it cannot do at all (note that I have not listed anything that Java is ideal for... there is a reason for that...). None of these languages are good for everything, either. There is no single language you can pick that is going to be good for every task. In fact, sometimes, it is necessary to use multiple programming languages in the same program to result in a quality application. Python and Lua tend to make fairly good languages for in-application scripting, for programs written in other languages that cannot be used this way. In high performance applications, it is sometimes necessary to mix assembly language with C, because even C cannot optimize performance perfectly. Even Python has mechanics for interfacing with C code, so that performance issues can be mitigated by mixing languages. Many programming languages recognize that there is not a single one-size-fits all language, and now I hope that you can see this as well. If you prohibit your employees from using the best tool for the job, you will likely lose your most valuable employees, and you will certainly end up wasting a lot of money on poor solutions that are expensive and hard to maintain.
There has to be a limit though. The fact is, there are some programming languages that are so obsolete or esoteric that they should not be used outside of an academic setting. In addition, not all businesses can afford to train employees in a new language as backup or even hire top-of-the-line software developers. Here are some good guidelines:
If a quick Google search does not turn up much information on a language, it is probably fine to tell the guy that wants to use it that he cannot. Your first stop should be Wikipedia. If there is not an article on the language, bail out immediately. No Wikipedia article means no community, which means no learning or problem solving resources. I once had a manager that convinced a company we were working for to switch to a different testing product, and we had a horrible time finding any resources or documentation. It turned out there was almost no one using the product, which meant that no one knew how to use it. When I discovered that there was no Wikipedia page, I realized his mistake.
Even if a quick Google search does turn up some information, take a good look at it. "Cutting edge" or "bleeding edge" means that if you choose to allow it, your company will be doing free beta testing for the language or product. Sometimes it is worth the risk, but you should be aware that the risk exists. It can also be worth spending a bit of time trying to learn what other companies are using the language. Haskell is not very popular, largely because few people are willing to learn it and functional languages in general are not very popular, but a bit of time searching will reveal that several large companies including Intel have enough faith in the power of the language to be using it.
Avoid hiring developers who only know one language. Anyone with a real education in computer science or software development will know at least two languages, if not 4 or more. It is true that programmers that are initially self-educated are generally better problem solvers than those who started college with no prior experience, but even self-taught programmers will have put in the effort to learn more than one language, if they are worth hiring.
Do not be cheap. You get what you pay for. Find out what the typical starting pay for software developers for your area is, and offer something close to that. This is a very competitive field, and if you are being cheap, you should expect to get only the people that no one else is willing to hire. To be clear, there are far more positions than there are qualified people. Companies don't turn away prospects because the position is already filled or because another candidate was more qualified for the position. They only turn away applicants who they will not hire despite the fact that they are desperate to fill the position. If your pay does not compete with these companies, they will hire anyone who is actually worth hiring, and you will end up with the people who are not worth hiring at all. The one exception to this is startups that may not be able to afford full price. This is an eternal problem with startups. If you are in this situation, don't sell yourself short. Admit that you cannot pay full price up front, but still be just as picky as your competitors. If you cannot find someone who can do a good job, cut your losses instead of hiring someone who cannot and failing epically. In many cases though, an honest startup can make up for the lower pay by offering part ownership or by finding someone who is so interested in the idea that they are willing to work for less pay just to be part of it. Overall though, being cheap will almost always cost you more than it saves you.
Lastly, do not restrict your company to a single programming language. Fire people who won't learn new languages. Hire people who already know multiple languages or who are at least willing to learn more. It might even be good to include an interview question about what language an applicant would use to solve a problem and why. (If you want to do this, keep in mind that the important thing is that the applicant gives serious thought to the problem. An applicant that picks a language because he or she is more comfortable using it might not be a good fit.) If you really have to try to keep it simple (you might want to see a shrink for your OCD), you can always require a written justification/proposal anytime an employee wants to use a language that has not already been approved.
I also want to mention: This is such a common problem that I hear about it all the time. Do you want to know who I hear about it the most from? It is mostly from very skilled programmers that quit their jobs when they got sick of trying to solve problems with unsuitable tools. It is mostly about companies who's products have dramatically declined in quality, ever since the decision to abolish all programming languages besides their "holy grail." I never hear one-true-language religious fanatics complain about this problem. It is always the well rounded software developers, with many years of experience, a large toolbox of programming languages, and a keen ability to pick the best tool for the job. In other words, don't do this, unless you want to lose your best employees, and end up with a team of marginally skilled "software developers" sucking money out of your company and hiding behind the facade of simplicity.
No comments:
Post a Comment