Nicolas Frankel is an IT consultant with 10 years experience in Java / JEE environments. He likes his job so much he writes technical articles on his blog and reviews technical books in his spare time. He also tries to find other geeks like him in universities, as a part-time lecturer. Nicolas is a DZone MVB and is not an employee of DZone and has posted 217 posts at DZone. You can read more from them at their website. View Full User Profile

The Dangers of Implicitness

03.26.2012
| 2880 views |
  • submit to reddit

This article is a reaction to the “Unlearn, Young Programer” article I read the other day.

It would be better if you would take some time to read it before, but for the lazy kind (of those I’m part of), here’s a short resume. The author seems to be a seasoned software developer. He makes the observation that when he tasks other junior developers to do some things, results are often not what he expected. In order to illustrate his point, he takes the example of having to hang a picture. I must admit the examples are very funny and speak very much to me. However, at the end, the conclusion is that young developers have to ask questions, period.

Take responsibility

As an architect managing developers from my ivory tower (read: not having enough time to coach them), it happens that I’m not satisfied with the results. I don’t know if it’s a trait coming from age, culture, country or whatever, but the first question I ask myself is what I didn’t provide my developer so he could achieve the results I wanted. This is not because I’m modest or insecure but because there’s a rule stating that you can only change yourself, the rest is up to the others. Thus, it’s not up to the developer to ask you questions (albeit it would be more comfortable for most of us), but up to you to give them as many relevant information pertaining to their job. Putting the responsibility on developers is too common a flaw seen in management that we should strive not to do it ourselves.

The danger of implicit

My second thought is about the gap between what is asked for and what is implied, because there lies the biggest problem. As an example taken from real life, six months ago, I had a motorbike accident in a foreign country (with police and ambulance and the whole show, but I had no wounds although I was a bit shaken). My bike was badly damaged so it had to be towed away. The trucker gave me his card, and I assumed he drove my bike to his garage, because that’s how it works in my country. Unfortunately, that was not the case: I only realized this when I received the notification that my bike was impounded and was destined to be destroyed by decree if I didn’t do anything about it.

How many times does such things happen in life (with less dramatic consequences)? As soon as you’re confronted with a foreign culture/country that seems similar on the surface, there are many chances for implicitness to creep through. Implicit is much worse than ignorance: when you don’t know, you won’t imply anyhting and most of use will be very careful about it. For software development, that means it may be better to have a Business Analyst who has no knowledge of the business domain. He/she will probably dig deep into every corner compaired to a BA who has knowledge of a comparable domain because the latter will make assumptions. Given Murphy’s law, that will probably be false assumptions, thus leading to dire consequences later in the project.

Conclusion

While I can only agree with the very graphic examples of the reference article, I strongly disagree with the conclusion. Senior software engineers should be as explicit as possible when giving tasks to more junior ones. While I have had the best work experience with programers that came up with questions, they’re not all like that despite us having to be successful in each project.

Published at DZone with permission of Nicolas Frankel, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)