Sunday, January 10, 2016

Six bad habits of programmers

Here are six things that many programmers do, but are a waste of time or plain counterproductive.

First, programmers say yes to impossible time schedules. I've done it myself too many times. Stop doing that and take some pride in your work, please.

Second, programmers follow so called "Best Practices". There are no best practices! However there may exist pretty good solutions to certain development challenges. But please make sure you actually have the problem before applying the solution. Remember that no solution is free.

Third, programmers love Inversion of Control. There is too much effort being wasted trying to decouple everything today. It will just make your code harder to read. And however easy it may seem to adjust your code for IoC containers, it is still extra work. Suddenly you cannot use a function you need without making sure that your class is known by and created by the IoC container. Extra work, and for what? Simpler testing? Do you even write tests? You certainly don't need IoC for writing tests.

Fourth, programmers write Service-Oriented code. What happened to Object Orientation? Remember the programming style where the programmer's knowledge is built-into the code itself? The data knows what methods are applicable. Why would you tear that apart and go back to procedural style programming where the data knows nothing of the functions? Waste!

Fifth, programmers use separate build systems. The IDE is there for you to use. It knows how to build your applications. It helps you set everything up, from source code location, library and dependency management, to deployment. Use it, use your IDE! Then use a build server that supports your IDE. Why should I use a separate system for doing all that, where I need to set everything up one more time, without the support of an interactive helpful tool? Ok, there is a reason: The current crop of IDEs are not good enough at dependency management, and the build servers don't support the IDE project formats well enough. Our world is moving to slowly. The tool makers need to speed up improvements.

Sixth, programmers access databases with ORM frameworks. And you need to access the db. You want some help CRUDing your data. Who doesn't. Let's use a great ORM framework. No, no, no! If you want to be able to change things, update your domain classes and keep improving your system you must stop, stop, stop using relational databases. The relational database is a dictator that owns the schema. Your code also wants to own the schema, the classes. The db and the code fight to rule the domain and both lose. That setup aint DRY. The code needs to own the schema/classes. You need to go NoSQL, and you need a db access framework that helps reading persisted data in older formats.

Archive