The other day, I was forwarded to a number of blog posts about Ego Driven Development, including:
I got to thinking about Ego Driven Development in terms of what I do and what I’ve experienced, even in the aspect of the way I code and have coded in the past. I’ve seen it in interviews where individuals that could barely drop a line of C code expressed braggadocio in writing their own file systems when necessary.
This also gets down into other things that I’ve read about what a Software Developer/Programmer’s real job is: solving problems. Our job is not to program our way out of every problem. If that were the case, there would be custom, unworkable databases at every company.
It is all well and good to write your own request dispatcher, object model, or ORM for any given language, but I would implore that you not use it for production projects. Generally, such personal projects should be done for learning software engineering or new programming principles, but not for production. When you use an generally available piece of software or set of classes for writing a production project, then it solves a lot of problems that you haven’t even thought about, beyond the items listed in the previous articles, here are some things that will make a huge difference to your bottom line.
Testing your custom piece of software is going to take a lot of time. If you don’t need to test the underlying mechanics, then that will eliminate a massive amount of the testing framework you will have to deal with. For instance, if you are working with Ruby writing a website, and you don’t use Rails (or some other similar system), then you need to write tests to analyze your request dispatch models. The most base part of your code – your platform – is something that you should almost never need to write tests for.
When you use Rails, Perl Catalyst or Dancer, ORMs that are Open Source and widely used, you are taking advantage of the work of hundreds if not thousands of developers, testers, project management, and other professions that you might not or will not have the time and money to procure yourself. In addition, these utilities are undergoing continuing development that you might need to worry about, but that you don’t have to pay for. Most changes are designed for backwards compatibility. Do you have time to do massive backwards compatibility testing in your platform code for hundreds of pages? What if you need a new feature that is probably already available in the vast majority of these web platforms and ORMs (I don’t know why I’m stuck in these, actually I do, but that’s besides the point)? You need to add it, test it thoroughly, regression test your entire stack, etc. You should have a regression test model, but what if something seriously breaks? Back to perhaps weeks of development on top of months that are just basically wasted time.
Seriously. It’s one thing to document your code, but do you have time to document your platform? It takes a significant amount of effort to write documentation about how to use your platform, and most of the time inline documentation is not going to cut it. For instance, have you tried to get a grip on how to use a library when the only available documentation is inline Javadoc? It takes forever. Compare that to well written external non-line POD available for DBIX::Class. Will you have time to write this documentation when suddenly the web site that you wrote takes off and you need to hire new developers?
This comes directly off the documentation point. If you have your own custom base platform, with poor documentation and no online tutorials, how do you train a new worker to use your stuff? If you are using Rails, Django (or another dozen or so common ones), you can actually just start by forwarding people to online tutorials if they don’t know how to use that particular item (and I don’t believe in saying, if you are working with Rails, you should only hire Rails developers; you should hire good programmers and problem solvers, they will learn fast enough).
If you have your own, you have to spend weeks, months, who knows, training them. Do you write documentation to explain this while you are training them? No, there are always other priorities. What if nobody has time to train them for a week/month/whatever? Now you are paying someone to be ineffective.
Usually, these other tools also have ways of adding necessary plugins to your system in a very easy way, as well. For instance, I’ve built custom models that linked my applications directly with RabbitMQ in Perl Catalyst. Writing a plugin model is not hard, but it is hard to do right. Using a good base platform encourages good engineering. Reading the code for a good base platform teaches even better engineering. With so many developers reading it and building on each other’s work, you are not likely to do better yourself. Of course, there is the possibility you could do better, but why? You could instead already be coding the website that going to make you famous rather than spending weeks solving a problem that’s already been solved.
There are times when you do need to rewrite large portions of open source solutions in order to improve speed or to suit your needs, but that probably shouldn’t be your starting point. It should be done after you discover that those things don’t work for you, and your custom solution will probably not require the flexibility of public applications.
When you are working professionally, it is time to leave your ego at the door, and solve problems. You will end up discovering that half of your work is configuration and configuration management, but that’s OK. Doing so will free you up to do great things, and to possibly make more money. Writing your own base systems, much like writing your own programming language, is great scholarly work, but when you are making something that you are not turning in for a grade, give it up.