Silence Implies Knowledge and Consent

I previously mentioned one of the best things I learned in graduate school, which led me to dwell on some of the other things I learned at school. One great piece of advice came from my high school math teacher, who said "silence implies knowledge". Essentially, if you didn't raise your hand or speak up when you had a question or comment, then he'd assume that you understood the topic being discussed, so he would thus immediately move on to the next topic and not look back. If you did have questions, though, he'd stop and take as much time as needed (well, within reason) to answer your questions.

I think his adage should also include consent - "silence implies knowledge and consent". So if you don't agree with something being discussed or have doubts about a matter, then you should voice your opinions and concerns. I'm not advocating just blurting out whatever is on your mind, but you can tell the appropriate moment when you should offer your thoughts. But if you don't say anything, then it should be assumed that you agree on the matter.

So in short, silence often works to your disadvantage; never hesitate to ask questions or speak your mind.

Should We Be Prepending 'I' to Interface Names?

Prepending 'I' to interface names was a habit I adopted when learning C#. I guess this naming convention is a carry-over from COM days, but it's usage in C# is still in effect - in fact, it is a MSDN recommended practice: “Do prefix interface names with the letter I to indicate that the type is an interface”. Yet why it is a recommendation is confusing, as it conflicts with other recommended practices, like "Do not give class names a prefix (such as the letter C)".

Even though this naming convention was odd to me at first, I've been using it for a while now without much consideration. But once again, Robert Martin has me rethinking how I write my code. In Agile Principles, Patterns, and Practices in C#, Martin writes:

"In general, it is a bad idea to pollute the name of something with an orthogonal concept, especially if that orthogonal concept can change. What if, for example, we decide that ICommand should be an abstract class instead of an interface? Must we then find all the references to ICommand and change them to Command? Must we then also recompile and redeploy all of the affected assemblies?

This is the twenty-first century. We have intelligent IDEs that can tell us, with just a mouse-over, whether a class is an interface. It is time for the last vestiges of Hungarian notation to finally be put to rest."

I agree with this comment. Not using the 'I' would make my code more flexible to change. It would also lead to better domain names. And honestly, I really don't care whether the thing I'm working with is a class or interface; I'm more concerned about its behavior.

However, preceding interface names with an 'I' is a widely-used convention in the .Net community. It's one of the few standards that every developer I've worked with has used. While I don't condone doing something because "that's how it's always been done", you could argue that since using the 'I' is so commonplace, it helps with readability. But I think the best reason for including the 'I' is that it makes for easy naming of the default (and often only non-test) implementation of an interface.

Nevertheless I keep wondering why interfaces need to be marked as special when IDEs make them easy enough to identify. This and the fact that I ultimately don't care if I'm working with a class or interface leads me to believe that we shouldn't be including the 'I' in front of interface names. However, it's not a practice that I'm pushing our team to adopt, as the current convention is popular and works well enough. It is something, though, that I'll try out on my personal projects, and it's certainly fun to ponder and debate. For instance, check out Brad Abram's post on this and the comments that follow.

I'm curious to hear your thoughts. Should we prepend 'I's to our interface names? If so, what are the compelling reasons to do so?

Is It Done Or Not?

One of my graduate classes was taught by a retired project manager who worked at a large, well-known software company during its heyday, and his lessons were sprinkled with advice and best practices from his years of experience in the industry. One of his comments, though, really jumped out at me, and I immediately took it to heart.

When talking about how people report on the status of tasks, my instructor mentioned that he only wanted to know whether the task was finished. He wasn't concerned about what percentage of the task was completed; he just wanted to know if it was done - a simple yes or no. His argument was that a task might be 95% done, but that remaining 5% might be complex or require the most time. So reporting the percentage of a task completed can be misleading and even trivialize the amount of work that actually still needs to be done - causing managers to believe that a task is close to being finished when it may not be. Reporting the percentage of a task that's done could also spur the developer or management to overlook or try to bypass the remaining work that needs to be finished for a task, when we should instead be focusing on ensuring that all tasks are "done done done".

So instead of giving a percentage, I try to simply state that a task is not done and then describe any obstacles that might be impeding my progress. Management then knows that work still needs to be finished but doesn't have any unrealistic expectations that the task is close to completion.

Polyglot Programming's Impact on a Team

Polyglot programming refers to making applications that are comprised of multiple languages, each used to handle a specific aspect of the application. Polyglot programming is becoming increasingly popular and will only continue to do so over the next few years - meaning that general purpose languages like Java and C# won't be the sole language used on a project and will instead be augmented with other languages. I'm all for this approach but have always assumed that it meant the entire team would be proficient in all of the languages used on a project. However, reading the chapter on polyglot programming in Neal Ford's The Productive Programmer has me reconsidering this notion. Ford writes:

“All doctors at one time were general practitioners, but as their field advanced, specialization became inevitable. Software complexity is quickly driving us toward specialization, both because of the types of applications we must write and the underlying platforms.”

I had never considered polyglot programming leading to specialization within teams - and perhaps throughout the industry. So I could be working on a Rails site and have a contractor specializing in Haskell come in to work on some tricky backend code that needs parallelized. Interesting. Though when I think about it, this specialization is already kind of present in our team. There's a guy everyone goes to with their JavaScript and CSS problems, as well as another who's known as our SQL and SQL Server guru. We could continue this and have other developers on the team become experts in different languages.

There are definitely some benefits of a team practicing language specialization. When a team understands a variety of languages, it increases the breadth of their problem-solving abilities - and more importantly, it allows them to leverage the best language for each particular problem. Furthermore, specializing enables a developer to become extremely knowledgeable and efficient in a language, allowing him or her to really maximize a language’s capabilities, instead of having a team of developers who are merely proficient in the language and don't use it to its full extent.

However, there could be some potential drawbacks to this approach. Specialization could hamper knowledge dissemination amongst teammates and possibly create silos within the team. Similarly, it could lead to a negative outcome in the hit-by-bus scenario. That is, what would happen if a teammate was hit by a bus? Would the team be able to substitute the missing developer and proceed with a project, or does the missing teammate have knowledge or a skill set that no other team member has, thus crippling a project if he or she is not there? I know we have at least one person like this on our team, and he sometimes has been unfairly pressured to work because his absence would severely jeopardize the completion of a project. This is certainly not a good situation for the team to be in.

Yet these drawbacks can be mitigated and will certainly not impede polyglot programming's rise in popularity. I'm uncertain, though, whether it will lead to a team and an industry of language specialists - but regardless, I better learn some more languages (starting with some dynamic and functional ones).

So what do you think? Do you agree that polyglot programming will become pervasive in the industry, and if so, how will it impact the makeup of a team?