This is an archive for some old comic strips I made many years ago about software development. The idea was to have fun with some colleagues, but it ended up in a website called codecomics.com. I hope you enjoy.
The Table Name
How many times have you developed test code just to check the feasibility of a particular implementation? Did you clean your code after you realized that things worked just as planned? Or have you considered the task finished and moved on to the next one? The behavior of the developer in the strip is much more common than we think. We usually see tables, classes, packages and variables with horrible names that could have been fixed if the developer had been a bit more careful. Remember that the code that you write will be read hundreds – or even thousands – of times in the future by you and your colleagues.
Unfair Firing or Not?
There are certain excuses that are unacceptable when it comes to firing a developer. The comic strip illustrates one of these cases and the reasons behind that are:
1 – There are tasks that will not result in code changes (e.g., investigation only)
2 – There are issues that require weeks of work, specially in complex / legacy systems.
When we analyze a developer by looking at his “number of commits”, “function points”, “lines of code” per time unit (months / weeks) we are looking at just one of the faces of the problem!
A developer that works on a very difficult issue will tend to commit much less than someone that has been working on simpler tasks.
We have to keep in mind that the developer might not be a specialist in the area he/she was told to work on. This would be – in fact – a management problem instead of a problem in the developer itself.
Your money or your life!
Third-party components, also known as COTS (commercial off-the-shelf) components, offer an alternative to companies that don’t want to develop certain functionalities (in-house development) and prefer to buy them from a given supplier. The savings that this decision can bring to maintenance costs can be high, but the details of the contract between both parts must be well-known.
It is possible to divide the component market in three categories:
(A) Without source code: The supplier company doesn’t sell the code;
(B) Source code for sale: The supplier company sells the sources and the binaries;
(C) Open source components: the source code is always available.
Several companies still avoid third-party components because they fear that the future changes to the product will not be in their control. In this case, the source code is essencial for the future actions, mainly when the component is not supported anymore. In some cases, it is required to upgrade the component regularly just to keep the support available, since the supplier might refuse to support the older versions. Open source components don’t have this disadvantage, but others may appear (e.g., abandoned projects).
All these details must be in the contract between both parts, which should include other factors that describe what should happen if the supplier is bought by another company or goes bankrupt.
How many times have you felt like the manager in the comic strip?
Are you already convinced that daily backups are important for you?
Don’t forget to backup your data regularly!
Note from the Author: Two days after creating this comic strip I lost my hard-drive and its data. You may think that it was the irony of fate, but we have to be always prepared for things like this. Blessed are the pessimists because they make backups.
How is the new report going?
New UI Components
In the comic strip above, Max would have to change thousands of lines of code just to put a new button implementation to work. Unfortunately, this happens in several languages that don’t provide interfaces to abstract the details of the services, which leads to lack of flexibility.
In java, for example, the Swing API has different components – like JButton, JTextField, etc. – that don’t implement an interface that could improve this flexibility. It is common to find open source frameworks with rewritten components (e.g., XButton, XTextField, etc.) and the difficulty to replace them in a system that already uses Swing is not trivial. In the specific case of UI components, the use of Look-and-Feels is a step toward this goal, since we can change the appearance of the whole system by simply changing a few lines of code. If you develop languages or frameworks, stay alert to this problem.
The right technology for developers
The mystery of the coffee machine
The dark side of pair programming
When day becomes night…
When your partner needs a vacation…
Increase the number of visits to your website…
How to drive your manager crazy
Where do programmers go after death?
The best paper for the printer