Posts

Why you should always add Licensing Terms to any software you distribute

I recently got involved in a debate on the topic of Software Licensing, and I found it sad that there is so little understanding, amongst Developers, of such an important topic. Together with writing complete and accurate documentation, knowing how to license your Software is one of the skills that any Developer worth his salt must have. At the same time, Users must learn how to read licences, and get the habit of doing it, unless they like risking to violate them without even knowing. Read more

How NOT to interact with non-technical Users

The content of this post has been removed following a complaint received by a reader.

The objective of this blog is to share experience with fellow developers in a constructive way. We acknowledge that the original post didn’t meet such objective, due to some non-constructive remarks that should have been avoided.

We would like to extend an official apology to anyone who was offended by the post, and reassure all our readers that we won’t be publishing such type of content again.

Repetita iuvant: you’re a Developer, not a Priest

Repetita iuvant (latin): repeating things helps.

In this case, I’d like to repeat a message I sent in the past, but that seems to fall on deaf ears way too often: if you are a Developer, you must not behave like a Priest. I felt the need of repeating it because, in a short time frame, I stumbled upon a couple of websites with messages such as “we don’t support Internet Explorer”. It’s annoying enough to see messages like this on sites made by nerdy teenagers, but when they are written by people who call themselves professionals, it’s unacceptable.

Also, do yourself a favour: don’t be like a guy I met once, who boasted that “his code works 100% on every browser“, when it failed miserably on any version of Internet Explorer. When I pointed it out, he replied that “IE is not a browser, and you are stupid if you use it“. Sure, IE might not be the best browser out there, but calling your potential Clients “stupid” for using it won’t bring you much business.

Being a Professional Software Developer doesn’t just involve coding what you like, when you like and only for what you find cool, but being able to support various technologies and making the most out of them. Keep your Technological Religion wars for yourself, grow up and get over it.

Or keep being stubborn, and just give me the contacts of the Clients you rejected, I’m quite sure I can help them. Your choice.

 

Code != Clothing, or How to neatly structure your code

Having been worked with countless technologies , frameworks  and 3rd party libraries, I can say that I have seen almost every possible way of organising the code for a project. From the approach of putting every file in a single folder “just for now” (where “now” becomes “forever”, because moving things around is just too complicated), to the one of creating humongous, monolithic do-everything libraries (which I nicknamed “walls of code”), to have everything is in one place, to the theoretically more rational modular system, where files are organized in sub-folders.

The reason why I stress the word “theoretically” is that, while the idea is certainly good, it can still lead to a messy, hard to maintain mass of files. The key of everything, in this case, is finding what logic should be used to structure the code. It may seem a simple question to answer, but the way one answers to it can lead to nasty surprises. Read more

The effects of Technological Religion – Case Study

This post is an addendum to Golden Rule: a Developer is not a Priest. For better understanding of the context, I recommend to read that post first.

Technological Religion is something I found in several places where I worked and, trust me, its effects have never been positive. I remember a case where the fanaticism of two teams was so strong that it created a barrier between them. Here’s their (sad) story.

Once upon a time…

In a town, somewhere in Europe, there was a Company in which two teams lived in not-so-much harmony. Read more