Skip navigation.

The Humane Programmer

Understand your limits, so that you can overcome them. A CC-BY-SA licensed blog.

Posts tagged with "engineering"

A theory about common sense

, , ,

In my many long days (and a few nights) of professional software development, I've had quite a few WTF moments. I'm sure you all know what I'm talking about - that moment when you look to somebody's else piece of code and you realize that he/she/them used the worst possible solution to the problem in hand, one of such devious ingenuity that you could never have created it, and therefore builds into you feelings of both fear and nervous laughter at the same time.

Every time I shared such a solution with one of my fellow developers who have the appropriate stature to understand the point, we were both thinking: this is nonsense! This violates the most basic mechanics of software development! This violates our common sense!

But common sense is a very elusive concept. How do you express it, how do you explain it to those people violating it in such an unimaginable manner? How can they learn it, use it, teach others? How did you get into its possession?

Hard questions, with no answer. Until now, when I have finally developed a theory of common sense. It may be proven right or wrong, but at least it's a theory that is, I believe, worth exploring.

My theory can be summarized as following:
  1. We start learning programming because we are attracted by it
  2. We continue to learn and read more and more because it's more and more interesting
  3. The knowledge pieces we gather connect to each other
  4. The connections solidify in patterns
  5. The patterns become the second nature and the common sense is born


The first empirical evidence of this theory was available to me a long time ago. I realized that the programmers that had common sense also touched a wide area of topics related to software and computers. I could discuss with them about all kinds of things, from the architecture of Linux kernel to functional languages, including topics from telecommunications, networking, assembly, electrical circuits or even unrelated topics like quantum physics, astronomy or genetics. One does not read such topics if forced, so they must have liked it.
On the other hand, the programmers that did those mistakes could not discuss any interesting topic and had almost zero culture in programming. Most of them had learned one programming language and one platform (.NET in my case) and were programming for money.

However, knowledge is not enough. I have also met people who knew quite some things about programming but had a crippled common sense. They weren't as bad as the WTF cases, but they had some repeated glitches. The brain plays a major factor here; the way it filters and organizes information can create very good systems or good enough systems of patterns.

My theory is also supported by some scientific research. A Scientific American article talks about The Expert Mind.


A chess master expert. Photo licensed under a CC license by mysza831

How did he play so well, so quickly? And how far ahead could he calculate under such constraints? "I see only one move ahead," Capablanca is said to have answered, "but it is always the correct one."



The article shows that the mind of an expert is formed by learning, practicing and working for at least 10 years. This helps forming a specialized type of memory that the expert uses for his work and that makes a very big difference between him or her and a beginner.

On the other hand, software development studies have shown that a good programmer is at least an order of magnitude better than a mediocre programmer. This isn't so unexpected when you know about the expert mind, is it?

In programming specifically, many studies have shown order of magnitude differences in the quality of the programs written, the sizes of the programs written, and the productivity of the programmers. The original study that showed huge variations in individual programming productivity was conducted in the late 1960s by Sackman, Erikson, and Grant (1968). They studied professional programmers with an average of 7 years' experience and found that the ratio of initial coding time between the best and worst programmers was about 20:1; the ratio of debugging times over 25:1; of program sizes 5:1; and of program execution speed about 10:1. They found no relationship between a programmer's amount of experience and code quality or productivity. (Code Complete, page 548)



And the final piece of evidence that I can provide at this point is a study on the ability of people to learn how to program. The study was initially called in a very suggestive manner The camel has two humps because it shows a large difference between the people who can learn programming and those who can't.


Expert pattern built by an expert. CC licensed work by Vilhelm Sjostrom.

Abstract: All teachers of programming find that their results display a 'double hump'. It is as if there are two populations: those who can, and those who cannot, each with its own independent bell curve. Almost all research into programming teaching and learning have concentrated on teaching: change the language, change the application area, use an IDE and work on motivation. None of it works, and the double hump persists. We have a test which picks out the population that can program, before the course begins. We can pick apart the double hump. You probably don't believe this, but you will after you hear the talk. We don't know exactly how/why it works, but we have some good theories.



In conclusion, my take on common sense in software development is:
  • Some people like programming and some don't - the camel has two humps
  • The people that like programming study a lot, forming their expert mind
  • The expert mind makes an order of magnitude difference
  • What we call common sense are the patterns found in the expert mind


Until next time, may the common sense become more common!

Software is walking in the clouds

, , , ...

By no means could I have missed the news that Microsoft has announced a new Operating System, this time a Cloud Operating System, named Azure. This comes in the context Richard Stallman telling that "cloud computing is a trap". To quote from the original article:

Cloud computing was simply a trap aimed at forcing more people to buy into locked, proprietary systems that would cost them more and more over time.



"One reason you should not use web applications to do your computing is that you lose control," he said. "It's just as bad as using a proprietary program. Do your own computing on your own computer with your copy of a freedom-respecting program. If you use a proprietary program or somebody else's web server, you're defenceless. You're putty in the hands of whoever developed that software."



One remark Stallman made becomes very interesting in the context of the wikipedia cloud computing description:

The interesting thing about cloud computing is that we've redefined cloud computing to include everything that we already do. Richard Stallman



Cloud computing is a general concept that incorporates software as a service (SaaS), Web 2.0 and other recent, well-known technology trends, in which the common theme is reliance on the Internet for satisfying the computing needs of the users. For example, Google Apps provides common business applications online that are accessed from a web browser, while the software and data are stored on the servers. Wikipedia



Let me pause this thread for a moment and talk to you about the other big problem on the internet today, copyright. If you haven't heard about the recent copyright technology craze, here are a few items:

Disney's release of its first Blu-Ray title, Sleeping Beauty, contains over one hundred and twenty pages of legalese when completely unspooled, including a 57 page EULA to access the BD-Live content and a 63 page privacy policy. Read more here



For software that appeals to a wide audience like EA's latest sim game Spore, it's sometimes the first time the average person gets a good taste of how digital rights management (DRM) puts the screw on legitimate users.

Spore's DRM limits customers to only three activations after the game is installed. That number isn't restored even if the game is uninstalled. Three is what you get unless you call up Electronic Arts customer support and give them your sob story.Read more here



Steve Jobs, Apple's chief executive, has confirmed there is a 'kill switch' built into the iPhone that allows Apple to remotely delete malicious or inappropriate applications stored on the device. Read more here



And one from the "cloud":

Google, I am a very lucky American who is living the dream of owning or being a partner in several small businesses. Each of these businesses utilize Google’s GMail and Google Docs, in an effort to cut down on infrastructure costs and keep an open stream of communication between all employees, contractors and clients.

Since Google has decided to take my account away from me, the nucleus of our company communications has been taken away and now is replaced by a black hole. My small business communications are now ruined until my account is reestablished.Read more here



So, to resume it:
  • You don't own the media you bought
  • You don't own the mobile device you bought
  • Your data is in somebody else's hands - now Google, tomorrow Microsoft, then who knows


On the other hand:
  • You can use software that you know exactly what it does
  • You can use open protocols that you know exactly what they do
  • You can use a device that uses this kind of software and protocols and operating system
  • You can use software you own to create data that you own that's stored on the devices that you own
  • You can choose to share, collaborate or give away for free your data on the internet if you wish to do so


Which list would you choose?

Which list do you think people will choose in the next few years?

What do you think this tells about them?

I think that too, but, on the other hand, I can't feel sorry for them.

As for myself, I do use google docs and yahoo mail, but I always keep a backup and I've never felt safe using them. They are useful, especially for collaboration, but I wouldn't use them for mission critical tasks. My connections, my business mail, my important documents are in places I can reach without going through google, microsoft or yahoo. Call me a paranoid, and I'll tell you that I'm an engineer and as such I think about failsafe mechanisms. As should you.

There are many more things to say about those topics; I think that the latest Felix' posts here and here bring other details in the story, as do many other internet links.

Until next time, keep it open, keep it safe!



Mosaic Works offers advice for choosing an outsourcing partner in Eastern Europe - FREE for the customer.

Why the CMMI or other standards have remained unattractive or avoided by software giants?

, , , ...

This is a question from LinkedIn that I answered today.

Why the CMMI or other standards have remained unattractive or avoided by software giants, compromising the software quality, and providing later on with service packs and patches to be applied?

Many software giants are not in the favour SW-CMM or P-CMM or any among the whole CMMI, just because they simply does not want the lengthy assessment to be performed on regular basis which may impact the right time to deliver the product, opening the major loopholes in the software product. Therefore, it is tendency to offer service packs and security patches after the software has been delivered without going through the quality procedures offered by CMMI like standards.



The short answer is because most software giants base their projects on people rather than processes. The Google example is the most well known, but Microsoft, Sun or IBM have similar policies.

The idea is that quality software requires discipline, and there are two extremes in the discipline axis: on one end you have disciplined people to work with and on the other you choose to follow certain processes to the letter. CMMI's focus is mostly on processes, while Agile methodologies (Scrum, XP, open source etc) focus on people.

This doesn't mean that a framework like Scrum has no rules; it does, but one of the first is that the team is self-organizing. I saw statistics related to Scrum and the results are impressive.

So, if you look to what software giants are using you will see that they are using one or more flavors of Agile: Microsoft is using MSF, Google is using Scrum, XP and some other flavors, IBM is using CMMI in some departments, open source and some form of agile in others etc. This is simply because a well implemented Agile framework gives much better results than CMMI.

Regarding the Service Packs and patches, in today's business world there is absolutely no way to eliminate them, no matter which methodology or framework you are using. You can reduce the number of issues through some engineering practices (which are common to all methodologies) like inspection, unit testing a.s.o., but the even if the software is perfect when you release it (which surely isn't), new threats and changes appear every day. So, the business reasons will push you to release new patches and service packs.

I don't say all this to defend Microsoft. I believe that their mistake is not in the way they build the software; it has much improved in terms of security and stability. Their mistake is in the way they are using the software as a business weapon; instead of doing the best software they can, they try to kill the competition with it. Sadly for them, it doesn't work anymore. Sadly for their users, they are still doing it.


Personal advertisement: I am PassionIT and I help teams develop high quality software. I train, I help improving and I work hands-on, depending on the needs. Contact me if you need help. Alexandru Bolboaca-Diaconu
Add to Technorati Favorites

Keep It Simple, Stupid (!)

, ,

One of the most successful principles of engineering, including software development, is KISS = Keep It Simple, Stupid. (I sometimes think of it as Keep It Simple, (you) Stupid!). Here are a few of my personal experiences with this principle.

Last year, a few co-workers developing a ticketing project came to me asking for advice regarding a role, permission and resource based access control system. The presentation of the requirements took about 30 minutes, and I was still confused on some points. Therefore, I stopped the discussion after the requirements presentation, asking them if the customer knows how intricate and difficult it is to define such a system. I told them that no matter which bright hacker they would have as consultant, the effort required will be immense. I mean, its complexity was similar to the Windows implementation of permissions. My message was, basically, keep it simple.

Talking about Windows, does anyone really understand Windows permissions?



For example, can you tell me what “Special permissions” are about? Did you ever see the advanced permissions? What is “Write Extended Attributes”? Honestly, to me, it makes no sense. I've never passed the phase where you create some users, add them in a group and give full control to the group on specific resources. The whole thing is too complex, and it's not really useful for most users.

Contrast this with the Linux way:

Every file or folder in Linux has access permissions. There are three types of permissions (what allowed to do with a file):

  • read access
  • write access
  • execute access

Permissions are defined for three types of users:
  • the owner of the file
  • the group that the owner belongs to
  • other users

Thus, Linux file permissions are nine bits of information (3 types x 3 type of users), each of them may have just one of two values: allowed or denied.
Simply put, for each file it can be specified who can read or write from/to the file. For programs or scripts it also can be set if they are allowed to be executed.

(whole article here)

Not only you can read and understand it in 30 seconds, but you can also relate immediately to what it talks about. It's useful, it's usable, it works. You don't have to think about whether you should:

inherit from parent, reset permissions, or overwrite them.

Another example is what happened about a month ago. We were discussing the GUI for editing a number of items organized in a hierarchical structure. Trouble was, save and cancel actions had the potential to create strange side effects. You would open a popup dialog, edit something in it, save it and the question was if all the items needed saving at that point. If not, then the referential integrity was not preserved. If yes, you saved the items from a popup who was supposed to save only the thing you edited in it.
After throwing a few ideas, we realized that there's a simple way to solve it: automatically and always save everything in background, like Gmail, Makagiga and other modern applications. This not only solves the referential integrity problem, simplifies the logic of the application but also proved to have benefic side effects in the code. A perfect example of KISS.

Another example is Mantis. Mantis is an incredibly effective issue tracker system, both easy to use and full-featured. It also happens to have a few touches of genius.
The first thing that made me say that was the fact that the issue number in mantis is unique, no matter in which project it is contained. This means that you can discuss with your customer about issue no. 1234566 and go directly to it, without having to navigate through the 100 projects of your organization.
Another splendid idea is the presentation of issues reported by a person who left your team. In mantis, you still see the name of the person, but it is presented with strike through, like this: Alex. Simple and effective.

Certainly, simple solutions are the most difficult to find. You need to invest time, involvement and lots of brain power into it. You need to keep reading, seeing what others are doing, searching ideas and have the courage to use them. It may not look so smart when you implement it, but it will certainly raise a few eyebrows when it's ready... Or, if you're really good at it, you'll say in the end: "I was so stupid. How didn't I think of this before?"


For anyone who's interested, here's some additional reading about how to apply the KISS principle:
  • Getting real, a free online book by the developers of Ruby on Rails, BaseCamp and other successful applications
  • The Art of Unix Programming, chapter Basics of the Unix Philosophy, a free online book about sound design, a must read for any serious software developer. If you don't have time, read at least this page; it's an amazing resource
  • The Humane Interface, a book about GUIs written by the man behind the MacOS interface, Jeff Raskin. It's not free, but you can find its summary online, along with many other essays by the same author.



Personal advertisement: I am PassionIT and I help teams develop high quality software. I train, I help improving and I work hands-on, depending on the needs. Contact me if you need help. Alexandru Bolboaca-Diaconu
Add to Technorati Favorites  Digg!

The Tester

, , , ...

The Tester is one of the most important member of a software development team. Unfortunately, in many projects I've worked, his/her role was severely underestimated, resulting in low product quality and high costs.

I believe this happens because testing is a more difficult task than the common sense tells us. Testing software is hard because it hits the same essential difficulty as all other activities in software development: software is constructed from ideas. It's even worse for a tester, because how can one check that the representation of an idea corresponds to the idea?

Because of this fact, a tester has to have a few key skills:
  • Smart, in order to understand the problem
  • Attention to details, in order to be able to find even the issues burried deep in the functionality and in order to be able to fill the missing details from the functional requirements (there always are)
  • Rigour, because he has to follow a process that allows him to check all functionalities, to recheck them periodically, to fill in the missing pieces and to improve the process
  • Empathy, because he needs to understand the users
  • Effective communicator, because he has to communicate both in writing (through test documents, bug reports etc.) and in speaking (with the developers, the business analyst, the project manager etc.)


If we add to those skills things like automatic testing, managing virtual machines and virtual networks, testing for security, stress testing and, the cream on the top, writing unit tests, we understand that a tester is a really complex character.

And a really important one, too. He has to work side by side with the development team right from the start of the project, because of simple economical reasons: studies have shown that bugs caught earlier are much less expensive than bugs caught late. Even a week difference between the moment when the bug is found may translate in a significant increase in costs: the developer locates the bug in a longer time, it's more difficult to fix it, it has to be re-tested and so on.

Therefore, if you want quality in your project, use a good tester and use him/her early. The price you pay for testing will be an investment, not an expense.


Personal advertisement: I am PassionIT and I help teams develop high quality software. I train, I help improving and I work hands-on, depending on the needs. Contact me if you need help. Alexandru Bolboaca-Diaconu
Add to Technorati Favorites  Digg!

The death of a visionary

, , , ...

I wrote before about the litterature of Arthur C. Clarke. I said then that I didn't think of him to be a good writer. However, I have the outmost admiration for him as a visionary and as an engineer.

As most people have probably found out already, Arthur C. Clarke died today. I am one of those who will regret it. In a sense, I've grown up with him, with his ideas and with the ideas that he inspired. Even though his books were not litterary interesting, they certainly were compelling from the engineer point of view.

I'm sure that, even though he died, we will still hear about him. I hope that the Arthur C. Clarke space elevator will soon see the light of day, along with many other of his ideas.

As an engineer, I'd like to learn from him how to imagine practical future solutions for complex problems. He was amazing in this aspect.

Mr. Clarke, I for one will always remember you, and will always be inspired by you. Rest in peace.

How to be productive when writing code

, , ,

I've gathered a few rules that, when followed, increase productivity of code writing.

Rule No. 1: Solve the problem in the simplest way possible

We are often tempted to think of intricate mechanisms that solve a problem. We are often tempted to generalize the problem and prepare for a future that never comes. We often solve another problem or we solve the right problem but in a complicated way.

I can empathize with this. There's a certain beauty to a system where many wheels turn in a perfect way and work together to solve a problem.

The trouble is that a complex system is complex to maintain. What initially seems a simple but powerful generalization, or the use of a beautiful method for solving a problem proves in 99% of the cases to be off target, difficult to understand, non-functional, difficult to modify, difficult to maintain. Therefore, a small "exageration" in coding produces a cascade effect that may live up to the end of the project.

When you think at it this way, you understand why everybody says that the code should solve only the current problem and only in the simplest way possible. There's always time for smarter approaches later (see rule no. 3).

Similar rules: Don't overengineer, Keep It Simple and Stupid

Rule No. 2: Write first, edit later

We have the tendency to think at better ways of solving the problem during coding. Don't do that: separate writing code from making it better.

Programming is creative work. You have to let ideas flow and to put them on screen as soon as they come. But when you do that, don't concentrate on all aspects. For example, error management can be added later. Methods can be extracted from existing code, once it's written. New classes can be created later.

I'm not saying that you shouldn't do any of the above when you write the code. Write whatever you feel natural to write, but avoid getting stuck in boilerplate or code organization issues. Make decisions on the way, as soon as possible, so that you continue to write code uninterrupted.

I've seen this work while writing the parsing code for the DSL I'm developing. If I thought of all the patterns, of the structure of the code a.s.o., it was ready in twice or three times the workload it took me. Sure, I have to revisit the code and refine it, but that's exactly the point.
Good code doesn't get born out of thin air; it is the result of multiple refinements.

So strive first to minimize the time needed for obtaining functional code. Add the bells and whistles later.

Rule No. 3: Refactor periodically

This third rule completes the circle. You solve only the current problem, in the simplest way. You write first, edit later. And you do this on a number of functionalities.

After a while, you realize that you can generalize parts of the code, or that some methods or classes repeat almost identically in different parts of the project. It's refactoring time.

But be careful: Refactoring means modifying the organization of the code without modifying its functionality. You are not allowed to add functionality (maybe only as a by-product). You are not allowed to change the existing functionality. You can do only a number of things: extract method, extract class, move method, simplify code etc. (you can find them all in Martin Fowler's book about refactoring).

And here you are: three rules for writing code better and faster.


Personal advertisement: I am PassionIT and I help teams develop high quality software. I train, I help improving and I work hands-on, depending on the needs. Contact me if you need help.
Alexandru Bolboaca-Diaconu



Add to Technorati Favorites  Digg!

The Ego in Software Development

, , , ...

I have recently stressed the importance of having a team formed from very good developers in order to obtain software quality. I received interesting feedback regarding this statement, including one issue related to the ego of programmers.

The problem goes like this: you gather your best developers and ask them to work on a project. Instead of producing much more than the average programmers, they fight over design, libraries and principles.

I believe that there are a few key problems when this happens. First of all, design by committee has proved to be an anti-pattern. Second of all, because software development is about ideas, all projects should start with prototype implementations that are refined during the project's consequent phases. Third of all, there's the Ego Problem.

It is easy to see that developers often have an oversized Ego. That aspect can be very good or very bad for a project.

Let's take for example Linus Torvalds. Whenever he talks in public, he says "I'm always right, you're wrong. If I don't like what you say, I may say you're ugly and stupid". That's certainly an oversized ego.
On the other hand, nobody can say that Linux is not a succesful project. More than that, Linux is organized in such a way that Linus Torvalds doesn't control all its phases. And there's even more to the story: Linux might not have been so succesful if Linus Torvalds had a smaller ego.

I've also met the other type of developer. The one who thinks that knows everything, the one that doesn't agree with older and smarter people from the industry. The one who thinks his ideas are very bright when they actually are really bad mistakes. The one that tries to impose his solutions to everybody else.
I guess that this phenomenon takes place in Romania because the IT industry doesn't have tradition, doesn't have values, and it's not settled yet (actually, like the whole society). People still try to be original when they should just listen to the voice of the experience.

But what is different between Linus Torvalds and John Developer My-Solution-Is-Always-The-Best?
You can probably name a lot of differences. Knowledge and understanding are a few of them.

I believe that the main factor differentiating a Good Ego from a Bad Ego is the intellectual honesty.

If you read what Linus Torvalds says, you will see that he has no problem to point out his mistakes and his limitations. That's normal, because he works in an open environment, where all mistakes are noticed. If he doesn't talk about them, the others will.
At the other end of the spectrum, John Know-It-All will never accept he's mistaken, even if you prove it with all the resources you can. He will find out all sorts of ways to prove them wrong: "Those people don't do what we do", "This is theory", "I haven't seen this work" etc.

So there's one point to look for:

A person with a Good Ego is his/her first critic.

Intellectual honesty also includes the willingness to learn. Not only the technology you work with, but everything related to software development. Yes, that's hard, takes a lot of time and it's frustrating because you always find out you made mistakes. But software development is hard.

Continuous learning is the best way to transform a Bad Ego into a Good Ego.

My experience includes many moments of enlightment and of realization of my mistakes. I've come to understand that mistakes are part of life and that we should take maximum advantage from them. Understanding our mistakes and finding ways to correct them is how we evolve intellectually. During this process, a Bad Ego is transformed into a Good Ego.

The answer? Look for people who are intellectualy honest. This is an absolute requirement for what I call "good programmer".


Personal advertisement: I am PassionIT and help teams that develop high quality software. I train, I help improving and I work hands-on, depending on the needs. Contact me if you need help.
Alexandru Bolboaca-Diaconu



Add to Technorati Favorites  Digg!

Threat modelling

, , , ...

I have a very difficult task those days: defining guidelines to ensure the security of a distributed application.

Despite the Oxford study that shows that engineers have a way of looking at the world that is similar to terrorists (?????), thinking as a hacker is not straight forward. And that's exactly what I have to do.

More than this, it's a job that involves great responsibility. It's important to review and validate all the assumptions and to test the results.

Anyway, I'm using the threat modelling methodology, which basically means the following steps:

  • Imagine all the possible attacks to your system (of course, there are already lots of papers describing possible attacks; I am using them as a starting point)
  • For each possible attack, evaluate its probability and the effects if it happens
  • For each possible attack, decide if preventing it is necessary and/or possible
  • For the remaining attacks, define the prevention measures
  • For all attacks define the contingency plan (what to do if it happens)
  • Translate the prevention measures in coding guidelines, test scenarios and maintenance procedures

Of course, in real life things are more complicated; for example data needs to be partitioned in sensible information (for example private data, commercial data etc.) and non-sensible information (for example lists of countries). Data Flow Diagrams are also very useful in order to follow exactly where the data is going, and so on.

Those steps should always be followed by many reviews, by training developers to follow the guidelines and by enforcing the guidelines.

I like this methodology because it starts from real world questions: What can an attacker do? How difficult is for him to do that? What are the effects of an attack? It also forces the analyst to learn about software vulnerabilities.

There is however another facet of any attempt to security: it always involves the human factor. I won't go in this subject now, but I recommend Bruce Schneier's blog for a very smart and insightful view on security, especially when it involves the human factor.


Personal advertisement: I am PassionIT and help teams that develop high quality software. I train, I help improving and I work hands-on, depending on the needs. Contact me if you need help.
Alexandru Bolboaca-Diaconu



Add to Technorati Favorites  Digg!

5 things managers don't get about software development

, , , ...

1. Software development is creative work

How do we know that's true: All rules that apply to creative work are known to give results for software development. For example: write the program, then re-write it at least once (see [1], [2]).

How do we know managers don't get it: The cubicle. The noise. Any other environmental factors that kill creativity.


2. Managing an IT project is different than managing projects in other domains

"In many ways, managing a large computer programming project is like managing any other large undertaking — in more ways than most programmers believe. But in many other ways it is different - in more ways than most professional managers expect."

(from [1])

How do we know that's true: Practices that work in other industries don't work in software development (for example adding more people to a project to make it end faster or motivating people with "the employee of the month" program)

How do we know managers don't get it: They still think people are interchangeable in a project team and they still use ineffective motivation and recruiting techniques.

3. People are more important than processes

How do we know that's true: No software company has succedeed only based on processes. Instead, all software companies that are very succesfull have very good people. The best example is Google.

How do we know managers don't get it: They still insist on the work processes instead of attracting talented people and instead of making sure that they reject the wrong people. (See [3] for an interesting story regarding this issue).

4. Good developers are cheaper than bad developers

How do we know that's true: Data from the industry shows that good developers can be up to 10 times more productive than bad developers (see [1]). From my own experience, there are cases when bad developers can be even worse than that. But good developers are never paid 10 times more than bad developers.

How do we know managers don't get it: They prefer to hire cheap but mediocre developers instead of hiring talented people.

5. No bad developer has ever become a good developer

How do we know that's true: Even Bill Gates said it. There are studies about it (see [5]).

How do we know managers don't get it: They still hope that bad but cheap developers will learn in time.

References:

[1] Frederick Brooks, "The mythical man month"
[2] Eric S. Raymond, "The art of Unix programming"
[3] Paul Graham, http://www.paulgraham.com/colleges.html
[4] Joel Spolsky about recruiting software engineers: http://www.joelonsoftware.com/articles/GuerrillaInterviewing3.html
[5] Saeed Dehnadi, Richard Bornat, Research Study about Programmer Aptitudes, http://www.cs.mdx.ac.uk/research/PhDArea/saeed/


Personal advertisement: I am PassionIT and help teams that develop high quality software. I train, I help improving and I work hands-on, depending on the needs. Contact me if you need help.
Alexandru Bolboaca-Diaconu



Add to Technorati Favorites  Digg!