As everybody in the IT blogosphere knows by now Jeff Atwood started quite some discussion with his opinion that there might be too many rules out there for developers to follow. I think the opposite is true. I think the IT industry is still a mess because 90% of the members of this industry do not know the rules, let alone follow them.
Sure it would be no fun to think about some 100 coding rules and guidelines for every line of code you write. It would be slow a tedious and would take forever. But thatâ€™s not the way it is working. All the good developers, the pragmatic programmers do stick to the rules. But they donâ€™t do that by actively thinking about the rules, they just learned the rules until they became their second nature. And only in difficult corner cases do they actively think about the rules, consider which one applies and if it might be one of the cases where you should break the rules. The problem is many developers do not know the rules and they will never learn them because nobody tells them I they donâ€™t ask.
This should change. I envision a future where programmers are trained just as a craftsman. When you are trained as carpenter or welder, you get to do really simple things. Like joining to pieces of wood or metal or making a cube exactly 5cm big. And when the angle is straight or if it is 5.1 cm big or if it has some ugly scratches you throw it away and start over. And if your join is perfect and the cube is perfect you throw it away and do it again. Until each and every join and each and every cube you make is really nice and clean. And only then you get to do these things on the real job, until after a couple of years you know all the skills all the tricks you need to work as a craftsman. During a large part of that time you work for some really experienced master whose main task is to train you and maybe 10-20 other apprentices.
Compare that to the education as a developer. At least in Germany there are three ways to become a programmer:
- You teach yourself and find a job. No formal training. It is pure luck if you found the important rules that really help you and prevent nightmares for the customers
- You study computer science and get a job as a developer. You probably know how a parser and a compiler work, how to proof an algorithm correct and how a Turing machine works. But chances are that you never did a branch in some kind of version control. If you did you probably did it in your spare time and not at the university.
- You get an apprenticeship. In this case you probably know how to do simple programs like a calculator. You wrote the calculator application once. And the source code sucks big time, but nobody told you as long as it works.
In any case very few of the new developers know even the simplest rules like:
- Use a version control system.
- If your code needs a lot of comments it sucks.
- Singletons are evil, most probably donâ€™t even know the singleton (anti)pattern.
What is the reason for this? Non developers canâ€™t judge software. When a table is not well made you will notice pretty quickly. It will wobble and finally break. But if software is a big ball of mud inside, you wonâ€™t notice. Sure it has bugs, but all software has bugs. And it is expensive to change it but you donâ€™t have anything to compare it to. Therefore junior developers or people that want to become developers get to work on real customer projects without any real supervision. Hardly anybody looks at their code, nobody tells them the rules and they donâ€™t have the time to train the rules.
So how should education for future software developers look like? Teach the rules. Give them easy tasks: Implement an algorithm; implement it using an iterative approach; implement it using recursion; implement it in java; haskell, lisp, fortran, groovy; make it as fast as possible; make it as small as possible; make it as easy to understand as possible; make it scalable for hundreds of processors; write tests for it until they reach 100% statement coverage; break the implementation of some other student without breaking the tests; write test until they reach 100% path coverage; break the implementation of some other student without breaking the tests; Train the use of version control, build tools and the like with the same approach. Check every single result a student creates. If it doesnâ€™t follow the rules let them do it again.
I think it is obvious that the IT-industry would be better off, when people get a lot of supervised education in programming. This seems to cost a lot of money, but I actually think it is a business idea! How about this:
Start a private software development school. Since you need the best teachers you get fees will be high. Arrange for scholarships by big IT-companies or let the students pay via some credit scheme where they pay only after they finished school. Come up with a strict curriculum. There is plenty input available. Also have a look at high end (military) schools. They donâ€™t just teach the main subjects, but also general knowledge and physical training is mandatory. So this as well as creativity, presentation techniques would find their place in the curriculum. Pick your students carefully and kick those out that donâ€™t meet the requirements. So why should people give you big lumps of money for this? How about a promise: â€œIf you finish school here we guarantee you an offer for a job with a salary of at least X$. If not we pay you 50cent for every $ differenceâ€ I am pretty sure, a school as sketched could promise that without too much of a risk.
What do you think? Would you consider such a school as a starting point for your career in software development?