Communication - A key to "Coding well?"

There once again seems to be a little wave of interesting posts on a new topic. Steve Yegge had a post on what happens when code gets to big. Then my friend Raganwald picked that up and started to dissect the idea. Steve commented that the goal of most coders should be to keep things small (gross paraphrasing from a much longer post), make the overall code base smaller so that it is more manageable and more maintainable. Raganwald takes that idea and makes it painfully obvious why that somewhat simple directive doesn't make full sense without some understanding of what it means to make the code base smaller - stating:

"These are my thoughts about the relationship between program size and readability. It’s my take on how you can look at one short program and dismiss it as Golf, and look at another and praise it as being succinct and expressive."

Raganwald points out that code size is certainly a factor in how manageable a particular code base is, but that a certain amount of code bloat is both inevitable and needed in some cases (my interpretation on the post). You see what I think he is attempting to point out is that its not all about the size but what the size is communicating, and what things went into getting the code base to a given point.

Programmers are people

We all have ways of talking to one another and we speak a similar language here in the USA but not all of us understand one another. There are some local inflections and dialects that can make modern English hard to understand just as if people were speaking two different languages. The same is true of coding even if you happen to be coding using the exact same tool or language. Even if all the programmers involved in a given code base are each coding well it can still be hard for them to understand one another's code. In the end we are all working in a community of programmers (unless we are self employed or working for the man) and we have to understand each other, but is the code enough to garner this understanding between programmers in this case? In my opinion if you were asking Steve Yegge he might say it should be... and Raganwald would likely answer probably not.

Dialects - what is a standard to you may be silly to someone else

So to throw a nail into this idea that even in one programming language you can have different dialects or ways of doing work Max Kanat-Alexander says the following about the Bugzilla code base:

* There are many ways to do the same thing in Perl. It's even the motto: "There's More Than One Way To Do It." However, this means that each reviewer must enforce very strict code guidelines on each coder, or must learn each coder's coding style. In the interest of consistency, we usually pick the former. This takes more reviewer time. It's also frustrating for contributors who are used to writing in a particular fashion.

* More ways to write the same thing means there are many more bad ways to write code in Perl than there are in other languages. In any language it's possible to do stupid things and not realize it. In Perl it's easy. Or even when the code does what you mean it to, just because it works doesn't mean it's good. My experience is that Perl encourages people to write code that "just works," but might not be architected appropriately. Once again, this is possible in any language, but I think Perl makes it easier than other languages to write bad code.

* It's very easy to make Perl code hard to read. It uses strange variables like $_. It relies heavily on complex regular expressions. I don't think anybody would argue that Perl encourages readability.

Raganwald, using design patters as a way to illustrate, makes much the same point. Design patterns are one more way in which programmers can attempt to communicate to other programmers their intention without having to sit next to them and explain it verbatim. Gecko on programming.reddit.com (shamelessly copied from Raganwald, because I don't yet frequent reddit) makes a similar point as an assignment anecdote to his life as a college TA.

So Whats the point

The point is that coding small is good provided that people will understand the smaller code. Code bloat is fine for the same reason but might hurt maintainability which is a different measure, and one should always know how they are being measured. Making code smaller for the sake of being smaller is not a good way of looking at it in my mind. Making the code base smaller when everyone understands how you are making it smaller is a different story.

No matter what you have to make sure that, at the very least, the programmers you are working with are speaking with a common dialect. In my mind not having a common dialect is what leads to a large code base and one that is unmaintainable - and is a problem in the end that can not be solved by simply making the code smaller and more concise as Steve suggests. The problem is also not one that can be solved by introducing Design Patterns although it can certainly help you to get to maintainable code base by virtue of having people understanding what you are saying because they understand your dialect. The problem is unfortunately a people problem and is still unsolved in programming, "how do I make people understand what my code is doing above and beyond what the code 'says' - because it doesn't align with my personal dialect?"

(as an aside I think that the last sentence is what leads to that programmer syndrome that makes all programmers think that another programmers code is pure unadulterated poo.)

What ENABLES you - is IT on your side

So the past few of my posts has been on development going faster due to help from the management perspective. Things like management removing impediments and not feeling high on themselves but instead taking the opinion and perception of the people they are helping as an indicator of the success or failure of their efforts. While I was writing that, my friend raganwald has asked us to stop blaming management. Now while I agree with that statement on the surface it goes a little deeper then I think his article implies.

So for a very long time programmers at the low to mid level have blamed architects and management for their problems. In some cases they even blame the business for their issues. What I have said in the past is that in order to address this blame game you first perceive that management is helping them. Step 2 is to make sure that you have your house in order. Step 3 is that the people running the environment you work in have to 'want' to help as well. Hence the remaining bulk of this post.

IT departments (from the top down) are more often then not run in a "command and control" fashion. What this means is that IT departments are often attempting to find ways to restrict what users can do, keep them from shooting themselves in the foot, make things as homogenious as possible in the name of making sure that they can support anyone and everyone in the company. THIS command and control idea is a fallacy and here is why I think so.

I believe very strongly that IT departments should be about enabling users to get things done. I believe that they should be more then willing to provide solutions that fit their needs, and when presented with something that doesn't fit the mold they have laid out precisely still be willing to accept things that make their end users go faster and get more work done. I believe they should be TECHNOLOGY ENABLERS not disablers, controllers, commanders.

Now what I am NOT saying is that IT should just willy nilly allow anything suggested, but rather they should work with people asking for 'different' things then what is currently being offered to understand what the need is and then move to fill that need. I mean that they [IT] should pro actively add features and functionality to provide users with choices. The down fall of NOT being this flexible is that users will want to work around the controls placed upon them. Human nature is to try and break free and do things perceived to be needed. The stronger the grip the more people rebel against it and the more things will slip through the grip.

So - which way does your IT department think? Are they enablers for their users, or are they command and control? I strongly think they should be the enablers - if for no other reason then not having to fire people working around their command and control systems.

OMG Moment in the car on the way home

So at Big Co. we have been looking at ways to change how management thinks and innovate how management works. To come up with new and interesting ways to make the work place awesome for the work force, to prevent turn over. In essence to make Big Co. such a cool and wonderful place to work that people want to flock to it rather then flee in terror.

To the point above some effort has been given to attempting to bring some problems to light. A series of presentations on management style, problem resolution, introduction of agile across the Big Co. enterprise has met with some interesting commentary more then once. The commentary has been about bruising the egos of the management with the things that are being said in the presentations. For example, a presentation might say something like "Management focus: Remove impediments" the response to this was something along the lines of "...you might want to reword that because people [management] probably feels that this is what they are already doing."

So here is where the AH-HA came in for me and why I felt this nagging bit in my head that the statement provided as evidence for 'dulling' that management focus statement to avoid calling someones baby ugly was a bad thing.

When we start our jobs in the Big Co. world we are all provided with instruction in sexual harassment. In this little bit of learning we are told that it is not the intent of the person doing the harassment that matters, it is how it is perceived by the person being harassed. So something that I might think is perfectly innocent someone else finds offensive and as such 'MAY' claim harassment. Having to reword the statement made above to avoid bruising egos strikes me the same way.

If the people that work for you are telling you that they do not feel that you are working to remove impediments to them doing their job there is no reason for you to be personally offended. In this case it is the workers perception of what you are doing as a manager that should be taken as gospel. It is the perception of management not doing something that made someone put a particular statement onto a presentation. Now sure you can say that you should be more political about it maybe... but reword it just because management already feels that are doing it? HELL NO, it is not managements perception of that statement that matters, it is the perception of the people making it that does.

Put another way, if you were the manager, imagine how in the dark you might be if you NEVER talked to the people you were managing. Those people working for you have insight and information. Those folk may be under informed of all that management is doing to help them - but if that is the case then the perception of not doing a thing is easily removed with greater transparency and communication. Tell things like they are and help management to understand that it is not about what they think they are doing it is about what people perceive that they are doing that counts.

Crazy is as Crazy Does - Joy in the job

You're a programmer, do you find joy in what you do or have you become Numb due to your employers "...wilful ignorance of software development principles..."? I think that Johnathan Dodds hit it on the head when he said

"I haven’t gone numb. I have passion and a sense of professionalism that’s independent of any company’s performance review.

Someone once told me that every workplace is crazy; the trick is to find a place that matches your kind of crazy."

So ask yourself, are you working for a company that is ok with your type of crazy? Better yet does your company SUPPORT your type of crazy such that it is not passed off or passed by but given the creedance that both you and the company feel is appropriate?

If not, why are you still working for them - start looking for a better fit - don't go numb, step up and step out and be both happy and proud of the things that you do. Find the job that fits your type of crazy, one in which you can let your hair down far enough that the company knows who you are and you understand the company. Don't let the work a day world turn you into a dull, numb, mindless programmer. Be passionate, be crazy - Suggest the outlandish and have the desire to follow it through to implementation. BE PASSIONATE about programming if it is your job. You should expect to be nothing less.