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.

Taking time out - the pause that innovates

So, in my current position I have been giving a great deal of thought to what I can do to help people be more productive in their programming jobs. I have been working with some wonderful people to both improve myself and to help Big Co. grow and become better at what it does in the world. One of the topics of discussion that has come up recently has been stirring in the back of my head. The discussion was around finding ways to innovate in the management realm to support doing "the work of Big Co." in new and innovative ways, ways that can not easily be copied by other companies because they are internal processes to Big Co.

One of the specific subtopics during this discussion was around providing time for people to innovate, time to pause and stand back, time to contemplate what it is they are attempting to accomplish or what it is they have been asked to do. I am writing about it now because as coincidence would have it this simple idea, the idea of providing people time to 'think on things', came up during a sermon I was listening to.

Now the sermon was about the Sabbath - the day of rest. What was said was that the world is moving fast. We all feel that things are faster then we would like - we even gage each other on how busy we are, almost as if it was a badge of courage, or something to keep up with like a busy/activity based keeping up with the Jones. This same feeling of quickness occurs both at home and at work. The work a day world at Big Co. is fast paced. There is a constant focus to get things done and get things done faster (translate that into getting more things done in a given time box). Put simply management at Big Co. wants their people to add value to what is going on in a faster manner. However for people in Big Co. to add value, I would argue that there needs to be built in time to rest, time to innovate, time to simply sit and think about what has been presented to you as the "THING that needs to get done." There is, however, a consistent lack of time built into the Big Co. schedule to 'contemplate', no time to pause and innovate. In short there is no Sabbath.

The draw back to this management focus on getting things done faster is that there is a myopic focus on the short term. The benefits right now are the focus. What this can leave out is future based planning. The other thing it can leave out are the "AH HA" moments that can result out of taking a moment to think about what is being done or asked for. Stepping back to see a larger picture can help Big Co. to plan better, it can help Big Co. employees to come up with innovative ways to solve problems presented such that they solve other well known corporate problems as well. As an employee you can better see connections between things. You may even have the time to have an epiphany that leads to Big Co. changing its direction and saving hundreds of thousands of dollars to the bottom line. Adding a pause between getting things done may simply prevent Big Co. employees from jumping ship to another company - but one could argue that just in preventing turn over you are saving the company money.

So the question is do you take time out to contemplate and think on things? Does your management provide you time to sit and think? If the answer is no please consider that taking time out for individuals might be necessary for Big Co. to grow to a new level, to expand into a new place. It may be specifically needed for individuals to grow and innovate as well. Stressed people think poorly, well rested individuals that are relaxed in what they do that have time to think clearly are setup to innovate. So are you set up to innovate or are you set up to be stressed the answer may surprise you.

Go Fast Myopia - Is your house in order

So my previous post was on getting the fundamentals correct. Why even bother writing a post such as that, especially about items that should be so self obvious to most programmers? Here is my rational. While we all know what the Fundamentals are we are not all working on them in our jobs. In fact in a number of cases we are ignoring the fundamentals all together letting Big Co. mandates and dictates impinge upon what we should be doing. Beyond that Big Co. may actually be dumbing down programmers in large numbers turning them away from the fundamentals because Big Co. may not know what the fundamentals are.

You see Big Co. focus is on getting more done. This focus is about getting more done in a variety of ways. Big Co. may be looking to get more projects done, they may be looking to get more features or more function, for the most part their desire is to see the company address business needs faster and more accurately. The problem is that this want by Big Co. to get more done seems to breed a certain type of myopia that is hard to get rid off. More importantly unless you have a special breed of programmer this myopia is contagious and can be deadly to the programmer organization.

So programmers are looking at the current code state and saying it is hindering efforts but it does not seem as if anyone is doing anything about it. Big Co. brass is saying you have to get twice as much feature function accomplished this year in comparison to last years numbers. They are saying you should go faster, so you try going faster, cutting corners, ignoring the fundamentals. You stop doing unit testing, you focus on getting to the end result. You accomplish your task faster, but now your code sucks and it takes forever for it to make it correctly through QA. You have not saved any time. Big Co. brass (CIO, Manager) takes all of this to mean that her team is moving as fast as they can already. Programmers may or may not feel this way but such is the Big Co. reality. They are slowly becoming more myopic and turning a blind eye because they don't know any better.

This myopia starts to make them look at ways to improve speed by adding people. Now I think we all know that this doesn't work, ESPECIALLY when you don't have your own house in order. If you don't have a good working code shop in place already how can you expect to get quality from an outsider? What outsiders will see is that they get to code in the exact same way that people in the company are. The result will be just as shoddy as everything else. No fundamentals, everything is a mess.

So how to you solve this myopic view that your people are currently at their maximum throughput. Put the fundamentals in place and enforce them. Give people the want and the need to do the fundamentals. Give them the time, help them to remove impediments, help them to understand that if they take time to help the overall situation they will be helping every one else to move faster. They will be removing the impediments to moving fast in the code. When this starts to happen it will help to have management removing impediments as well. They can help by pushing on the business long enough to solve the biggest problems. They can help to rearrange people in the organization to remove people issues, resourcing and a variety of other things. Big Co's myopic view that we are at our max starts to change and they see they are not moving as fast as they could. Big Co. brass starts to see that they can influence change in ways other then just adding more FTEs, which we all know doesn't work.

So whats the moral of the story? Since we know that adding people doesn't work (or at least doesn't help as much as one might expect) do you know that your own house is in order? Is Big Co's myopia bleeding into your job? If it is take time out to attempt to educate, work to get your house in order - SHOW everyone that the fundamentals can make things move much faster. Make sure Big Co. knows of their own blemishes and is working to solve them before they look to add more people or offshore, make sure your not myopically ignoring your own problems.

The (Fun)da - mentals : Are you getting what you pay for?

Is your code or code base a mess? If you think it is do other people that you work with also think so? Do you constantly feel like you 'HAVE' to rewrite the code (more then a simple refactor)? If you answered yes to any of these questions I have one more for you that in part attempts to address the above questions: Do you practice what we all know are the fundamentals of programming regardless of the language you happen to use? Lets turn the rock over and see.

So you say that the speed with which new business code can be developed is slowing down. Maybe you are even saying that new implementations of business features are being hampered by the existing code base. Lets assume for the purpose of this post/discussion that you have been in your current position long enough to notice and potentially make comments about problems that you are spotting in the code base. Lets also assume that you are attempting to be constructive rather then just calling the offending code items pure tripe. When you speak of the offending code what are you saying? What I tend to say these days is that it doesn't meet the fundamentals very well. People often ask me what I am saying when I speak of fundamentals when looking at code. So here is what I explain.

You have to want to learn from past experience, by this I mean both the past experience in the company itself but also the past experience of developers that may have tread where you are now. Keep in mind that there is almost always someone that comes before you and they may have done something similar if not exactly like what you are doing now, at some time in the past. It does happen now and again that you get new novel problems to solve, but these are becoming more rare in corporate America and more the stuff of universities and start ups. So start by attempting to address what happened that lead to where the code is now.

Now you have some history - you can attempt to look at the specific areas in the code that are not done well, you can start to focus on the specific items that make you want to say "I need to rewrite this code" (beyond, of course, your personal distaste of the implementation). This is where the fundamentals come in.

So we all know what problems can exist in code but it might be interesting to see a refresher, so here it is. If you think / want to rewrite your code base and you have done your home work on this history then you can use the fundamentals to start bottom up and address the programmers actions that got you to where you are now.

Code smells - generally after working in a code base for a little while I bring this up as a topic to investigate. Code smells can lead to a code base that no one likes to work in. Teach your programming team to notice and raise these smells as concerns more constantly. Visibility makes these items hard to ignore and you can start to quantify what draw backs the code smells are providing to getting features implemented.

YAGNI - You're Not Gonna Need It. Lots of people ignore this one by way of attempting to be overly flexible in their implementation to attempt to accommodate a schizophrenic business that can not decide on what is the most important thing to do in the company. This is larger then the programming team, but is certainly one of the fundamentals that should be applied and paid some attention.

DRY - Don't Repeat Yourself. The urge to cut and paste working segments of code from one place to another is tempting. However when you find yourself taking the same block and copying it all over the codebase it starts to scream out that you should do something to provide that block as a common item rather then blindly copying the block all over the codebase. Both achieve usage, and both styles work, but when copying the block all over the place if the business logic in it changes rather then one spot you now have many to go fix. Taking more time then you need to to make what should be a simple change.

KISS - Keep it Simple Stupid. Along the lines of YAGNI this is a big fundamental item. Do not over complicate the problems you have, solve them. Solve them elegantly if you can and if not do just the minimum that solves the issue. Don't over do it, don't gold plate, and don't over complicate it. All that over complication will make things harder then it need be later in maintenance mode.

Fail Fast - In almost all cases you want your program to fail fast rather then waiting to bubble up and error at some point in the future. Future based errors or attempting to run when a part of the process is known broken can cause errors that occur much later, and disconnected from their initial cause. This makes for a nightmare debugging, root cause analysis problem. The error is not connected to its root and as such nearly impossible to find.

Refactor - Good god - this might be the most important of all the fundamentals. If you are not taking the time to notice problems and then make them visible and then ADDRESS them you might as well be ignoring a wart on your nose. Refactor always and do it within the confines of the other fundamentals and the risk tolerance of the place you work.

There are many more fundamentals and I would encourage the reader to do the diligence, go find the other fundamentals. Work them into how you do your work, attempt to work them into how your teams of programmers do their work. Use them as guidelines to development and you might be very happy with the result. You may find that over time the ship seems to steer itself and the codebase starts to look better and you don't feel like the code you work with is complete poo all the time. Let your bosses get what they paid for, a seasoned developer that will work to both improve the code, the people they work with and the processes of the company.

Debuggers are just another tool

OK, admittedly I have gotten caught up with a discussion that caught my eye. It caught my eye because I have been holding a post on the topic of debuggers for some time now and it has provided an excuse to go back and finish it, so here goes.

Debuggers are just another programming tool to be utilized when needed and as needed. It is my opinion that programmers starting out should avoid them like the plague and here is why:

Debuggers are like a crutch when it comes to figuring out what is going on in code. Debuggers are amazingly detailed allowing line by line inspection and manipulation of items in mid flight while the code is bing executed. This power, when you are new to programming, is enticing. However having this ability is akin to the draw of the dark side of the force, wild power with no control is a problem. (Note: This crutch can also be abused by people that have been programming for a long time - so please don't think I am singling people out here.) Debuggers as a tool are great, as a learning or teaching practice, I believe them to teach the wrong things.

Debuggers bring about a certain complacancy that I think hurts the programmers and the people they work with and for. Some programmers get to thinking that they can solve the problems they run into by simply saying "Oh you are having X problem, well we'll just attach the debugger and see whats going on..." when in fact there are a fair number of situations where that can not be done. The large for instance is companies who are large enough to have a "production" environment are not inclined, in most cases, to just let a programmer "connect" in such a powerful way to a running production application. So what do you do in this instance? Lets break out the swiss army knife and see.

1) Utilize TDD up front - use your tests to ferret out as many of the bugs as you can find. In some cases this testing my actually help you locate things like race conditions and so on (assuming the test was written to do that).

2) Effective Logging - NOW here is a topic that people so often skip over. So many times in my life I have said "I wish the person who wrote this had logged something in this location where this very important state changed because of X" that I would be rich if I got a penny every time I said it. This is also a topic that is rarely covered in any learning or teaching in school. In fact I don't believe that ANY class I have attended or heard of teaches this as a topic. IT SHOULD BE, even if it doesn't cover it in depth the topic should be discussed.

3) Cleaner code - This is hard to quantify, but one could pose the argument that cleaner, simpler code would have less bugs simply because it would be more straight forward to understand.

Is there a black and white in the use of debuggers - probably not. Like I said above it is just one more tool in the arsenal. Since we already know there is no one tool for all jobs it should be safe to say that debuggers should be used when appropriate. Finding those appropriate times is hard however given the ultimate power debuggers can provide.

In the end just because you write tests doesn't make you ignorant of a debugger(s) nor does using a debugger mean that your language of choice at the time can not run tests gracefully although it may be true in some cases. Debuggers are also certainly no silver bullet, but then again neither is TDD, but doesn't mean that I should abandon one for the other. Each person is going to use the tools that they think best fit the bill. In some cases they may also choose to sharpen their saw with a blunt instrument. Now while using a debugger is not my first choice I can recognize that it is a tool I can use to help solve the problems I have, point out where I need to add logging to legacy applications, or even write tests for things I know nothing about when I start my day. Debuggers are bad for learning, and can be bad when used improperly - but I would certainly shy away from a black and white statement that says ALL debuggers are bad in ALL situations.

As a side note on reading Giles Bowkett's blog post on this topic I noted in his comments about the vile nature of the posts on his blog. We are a community folks, the community is what makes us strong and in my opinion strong opinions make for wonderful debate and make us all better at what we do. HOWEVER: when we loose our respect for others be them users or fellow programmers we are doing our selves and our community a large disservice.

Programming and Community

So my last few blog posts got me thinking about how I personally approach programming and the job I do from day to day. In fact a sermon delivered by my Unitarian Universalist minister this morning solidified for me how I think about my approach to programming. The sermon was on Big P and little p politics. What struck me about the sermon was how well a conversation about our little UU community fit with the programming communities that we all work in (assuming that we do not work for ourselves or alone).

The sermon described Big P politics as things like espousing to vote for certain people, or telling people that they should think a certain way. While little p politics, our minister goes on to describe, are the things and actions that we take in our community. The important part of this second "little p" politics to me was how she described what was vitally important to the topic, the ideas of D and P.

In this case, she joked, she was not talking about Democrat and Republican and by using it I am not talking about Theory D and Theory P but rather she was speaking of DIALOG and RESPECT.

These two ideas should be one of the corner stones of what we do as programmers. We should all be capable of entering into a dialog with our fellow programmers in a mutually respectful way. How does this translate into the world? Any and all of us should be willing to have our minds open and be able to enter into any conversation about programming being willing to change our minds about a particular topic that previously we may have taken for granted. i.e. we should treat our community of programmers with respect and always be prepared to have our pre-conceived notions challenged and overturned by someone else.

This idea of dialog and respect can be powerful - and transformative (along the lines of Reg Braithwaite's post on blog postings he would love to read), but we must be careful about the definitions. By dialog we are not talking about flame wars (these are dialogs yes but not constructive ones in my opinion) - but rather an open and free conversation between people of mutual OR dissonant intent. This second idea (of speaking to non-like minded folk) is very important to the this topic of dialog and respect in the following way:

If we choose to spend our time only talking to people that we know hold the same ideals as us we are not challenging and we are not learning.

If we only speak to like minded people we are foolishly sticking to our guns and have become logically 'stuck'. We may also have stopped acknowledging that others may have something important and vital to contribute and as such are not respecting them and their learning. Only when we are open to having conversations with both like minded and dissonant thinking people, having our minds changed/challenged, are we approaching any dialog with respect. This is what can make us better, raise us all up a level, make our community stronger - help us All to get along.

The idea that little p politics can play this roll in our every day lives can easily be missed, but I encourage all readers of this blog not to ignore it. Take time to realize what effect you may have on people you work with from day to day. Pay attention to the effect you may have on the organization and community at large. Use the little p politics to strengthen yourself and our programming community - the large and the small - the world as well as the Big Co. programming group you work with.

Learning (revisited) and Transformation

So my friend Reg Braithwaite over on his blog posed that he would like to see people make some posts about:

"1) What I learned from Language X that makes me a better programmer when I use Language Y

2) Something surprising that you probably wouldn’t guess about Language X from reading blog posts

3) My personal transformation about Idea X"

in his post: Three blog posts I'd love to read (and one that I wouldn't). So here I am attempting to take up the challenge, an blog about 1, and 3, starting with 3.

So the transformation that I went through was pertaining to all other languages (i.e. the ones the I am not currently working in) and it was simply that they ALL have something small to contribute when it comes to how I program from day to day. I previously felt about programming like I felt about doctors, it is better to focus in and be specialized then it is to have broad knowledge about a bunch of information about many different languages. When I finally started to gain knowledge in those other languages I finally realized how wrong a path this was. This THEN relates to item number 1.

So this transformation in my thinking (which is a bit of a gunshot in the head if you were thinking in this very one line type of way) brought about all the other things pertaining to what I learned in those languages that I could apply over all. The first new language that I picked up was Perl, and then I picked up Python and Jython. Each one of those languages had a large impact on how I thought about my java programming. Each of those languages does things differently and sometimes better. What I walked away from each one with was simple at first. Things like formatting and the need to document the code with comments (simple but needed). Then other simple things like structure of the code and flow control. Then GRAND things started to turn over in my head like if perl does it one way and it rocks in perl, how can I make my java code JUST as elegantly do the same thing. The transformation was a big shift for me. It then fed back into item 3 in the form of "If these two languages can modify how I think about what I am doing now in such large and interesting ways - what else is out there that can help me?"

So the learning now goes on with a much much more open mind, and a puzzle piece mentality that I think benefits both me and the people that I work for in immeasurable ways. Taking notes and ideas from many places to form a more holistic view of programming.

Why so passionate? Can't we all just get along?

OK, this might seem a little silly but I have now seen at least three separate posts on the very same topic. It all started with this post over on raganwald: Java is the right answer to the wrong question, Ruby is the wrong answer to the right question which opened up with a quote.

"Large code bases are the problem, not the language they’re written in. Find a way to break/decompose big code bases into little ones."

Bill de hÓra, calming a heated debate

Which addresses a topic that comes up a great deal. This quote is used as a jump point to discuss the ongoing silliness that we all seem to occasionally get mired in, which is a discussion of why one language is bad and another good... or in some cases why a particular feature of a language is bad and another feature in a different language is good.

What if There is no One Answer to the question of which language to use, or if static typing is better then good unit testing? Is it really so hard to grasp that one should use the right tool(s) for the job at hand? As a for instance, if you were building a deck on your house you might pick supplies for that project that you like but you would balance that choice with the needed strength to make sure the deck does not collapse after it is built. Why does the discussion of things like Java vs. Ruby and Static Typing vs. Unit testing always have to break down into a feces throwing match?

Lastly Bejamin Stein asks How confident are you, the programmer, that the change you just made will work? In my opinion this is a sub question that SHOULD get asked after the correct tooling has been chosen. As a programmer I have a desire to know that my change isn't going to effect the world, lots of tools can help me with this (not the least of which is a simple grep). I would also hope that my chosen tool for a project can help me with knowing what a change may effect but that may not always be true because of the type of project or type of tool chosen. This question may also only apply to larger (i.e. Medium to Large) projects with multiple people because knowing your change doesn't effect everyone may reduce work someone else has to do making the teams you work on faster as a whole. If I know it is just me writing the code for me and no one else I may not care if I effect the world because in the end I have to fix it anyway.

All I want to do is get along - Choose the right tool for the job at hand, and have some good support as to why that tool was chosen. Be it statically typed, dynamically typed, easy to write a unit test for - or not so easy. Different projects, different tasks, DIFFERENT tools, perhaps even a DSL tossed in for good measure.

The Morale Morass

In a follow up post to Brian Hurt's post on the Second Derivative of coding (Use and Re-Use). Robert Fischer expands on the same issue and has some wonderful additional thoughts from his own experiences with this same topic. The article does leave a large unanswered question at the bottom that I wanted to take a stab at answering, that is, how do you keep developer morale at a given organization high? Robert states that coders with high morale will be more communicative and more effective writing better code - the type of code that can be re-used, the type of code that will increase the speed of the team to get things done. The type of code that accelerates the team as a whole.

I have to agree with his end points. Coders that have a high morale tend to be like he describes, they want to help everyone go faster and more importantly they want to solve problems or speed bumps that they see getting in the way of going faster. The question of course is how do you keep your coders looking bright and shiny with a glossy sheen to their coats?

My simple answer to this question is: Listen and respond to their issues.

Lets assume for a second that you have done a reasonably good job at hiring some great coders. They may not all be spectacular but they are certainly a cut above. These people have been working for you for some time now and have started to provide feed back to manager(s) about what issues they are running into in the code. They are providing feedback about what happens when they attempt to solve business issues by developing functionality and the road blocks in the code they run into. The items that they bring up might range from something as simple as code organization to something as complex as how some 20 class files make up this bit of business functionality that could have been done in 10 classes with fewer code smells. What counts is that these complaints are HEARD in some way (meaning there has to be a way for the developers to attempt to address these problems both as a group and as individuals). If the comments go ignored and there is no time to address the issues, then morale suffers as does the code - because you start to fall into the negative acceleration phase of your second derivative. If no one is listening and ADDRESSING the issues over time the code is harder to maintain, harder to deal with and functionality is harder to implement taking a longer period of development. It turns into a cascade failure.

Coder morale is a hard thing only if you make it hard. Keeping your coders happy should be easy - it should be as easy as listening and addressing the issues they raise. Some of these issues may take a long time to address but as long as progress toward resolution can be seen most people will be more then satisfied to know that things are moving forward... the issues are getting resolved and importantly they are getting listened to.

Factor/Refactor - get fast and stay there!

Something that I saw in two different posts recently got me thinking. The first post had to do with abbreviation and accidental complexity, the other was on Use and Reuse of code. The topics are intertwined and linked.

The commentary on Raganwald attempts to point out that just because something is brief it is not necessarily better and at the same time the reverse can also be true, that something verbose may not be easier to understand over all due to accidental complexity. Programming is about finding the balance between the two points. In other words the SNR (Signal to noise ratio) in ones code is an important factor. This leads to the second article on Use and Reuse of code.

I especially liked the commentary that Enfranchised Mind's Brian Hurt provided here, that the Use vs. Reuse of programming could be considered the Second Derivative of programming (remember back to all that calculus, the second derivative is acceleration). Stated in another way, that whats important in programming is the ability of a coder(s) to add new code faster and more efficiently in a constantly changing environment.

Why is this so important? What makes this idea of adding new code faster and more efficiently such an important topic to cover? Well, the reason that I have been finding it important lately wraps around to another fact of life - systems of things (programming software or otherwise) tend towards entropy and need attention to be held at their current state or improved in anyway. This plays out in the following fashion:

An existing system of code lends itself to doing certain things in certain ways. This way of doing things often represents the way in which the programmers 'thought' that certain bits of system code would be used in the short term. Those same programmers my have been forward thinking about needed changes or potential other uses but lets face it we are all not prognosticators and can not read the future. That being said at some point in the future the code is going to need to be modified to suffice some additional need. Now the question becomes how hard is it to suffice this new need given what currently exists. If it is hard to suffice this new need because the code is not structured in a way that allows its reuse then the coder is going to have to slow down and possibly implement a bunch of things she did not intend to. This temporary slowing down / refactoring is IMPORTANT as it makes the system more resilient to the 'new' types of changes being requested and it keeps people chugging along at top speed (or close to it).

Here is the practical take away, systems that do nothing but implement new stuff all the time and pay no attention to the things that pin them up (the pillars or underlying architecture) will eventually become so decrepit as to actually slow coders down when attempting to DO anything with the code. Refactoring is a necessity to keep people using and re-using code. It is the re-using that keeps the speed of implementing new things high and allows development to accelerate and succeed. The best case is to have accelerated (by re-using code) your development to the point at which it is lightning fast and hold it there devoting some percentage of energy to not decelerating from that really fast point.

What I Learn(ed) from Others

WARNING: Generally off topic for a bit of praise

In my career as a programmer I have attempted to learn as much as I can from my mentors and my peers. I have learned a great deal from the people that I have worked with, things like:

1) Don't rely on a debugger, log what you need when you think you'll need it. This will treat you a great deal better then the debugger.

2) DSLs can be an important thing to think about when presented with certain types of problems.

3) Java script can be fun and informative if you use the 'right' tools.

4) Always question and be curious - it will serve you well in your travels

and finally

5) Don't burn the bridges that you build, it will come back to haunt you.

All in all I think that I have come a long long long way from where I started out in the work world. Also I think that I have a great deal of thanks to be paid to people that have helped me along the way. Which brings me to why I decided to make this post... one of the people that I have been working with, someone who has taught me a lot both in working with him as well as reading his blog postings has decided to move on and find himself a new position.

Raganwald has been a great mentor and colleague and has brought a great deal to the table for me but has decided to move on. I am personally sad that I will not get to interact with him on a semi-regular basis in the work world anymore. I have learned so much - and certainly feel that he has more to offer. He thinks out of the box - aiming to simplify and make programmers lives easier. At the same time that thinking is about solving the problems presented in a novel and efficient way. I wish him the best of luck in his travels - I hope that he knows he will be missed.

Conjuntion junction meets Certification Specification

A post over here at Raganwald got me thinking the other day. The post was about certifications for programmers and got started by posing the situation where he posted his resume with a recruiter and got back a request asking him where he attended college. The post itself goes on to discuss certifications (ala getting a degree) as a means to attempt to discover if someone is capable of doing the job at hand or the job that they are being requested to do.

This same post goes on to point out that in some respects certifications may be of use, but that the certifications might be working on the wrong things in order to pick out a good programmer. This post was also picked up over at Enfranchised Mind where the writer attempts to point out how Raganwald may have missed the boat when he stated that his programmer certification test would consist mostly of understanding the different ways in which you can be measured as a programmer.

Personally I think they both gloss over the nits/grits of the issue. Raganwald is correct, IMHO, in saying that he thinks that in order to be a good programmer you need to understand what you are being measured with. If the objective measure is a ruler, then anyone can be a good programmer. If the objective measure is how many lines of code you write, then a bunch of monkeys can be good programmers. IF however your measure is how much code did you write that:

1) Solved the problem that you were presented with
2) Solved it in as few a number of lines of code as possible
3) While simultaneously not producing any (or at least as few as possible) bugs

Then the pool of people that you are talking about being able to do the job suddenly gets quite a bit smaller. The understanding of this is important and I believe that he is attempting to point out the importance of knowing what your measured with is one of the important points of being a programmer. More Specifically that his certification (at least a first level certification) would have the programmers he certifies understanding this point in depth and completely before he would let them loose on the world.

The other blog article seems to wander off into the weeds a little and points out some things in the Raganwald article the he takes deference to. Then wanders into a diatribe about Ocaml and static typing (possibly as a dig or as an attempt to point out that he is not a Blub programmer). I think the thing this second article gets right however is that learning what makes a good programmer is an ongoing process. That in general people are still trying to get a good handle on what a good programmer is, and how they work. Which begs the question again of what individuals are using to measure against.

The point that I think they both miss is the thing that it is hard to discern in an interview "What has your experience brought you above and beyond the basics that make you a good programmer for BigCo?" I think the question says it all - a good programmer for a given place. Each programmer will bring a different eye and a different experience to what they do. An older more seasoned programmer might be what you are looking for, but seasoned in what way? It is difficult at best to, in a 30 minute interview, understand what a singular person brings to the table - so does the certification help? Is it about what language you write in/know?

I would argue that it isn't about those things - its about what information you bring to the table, its about the "Learning" you have done over time. Its about the intangibles - the things that are DAMN near impossible to 'test' for that make you a good programmer. There are certainly some things that you aught to know (like how you are measured) - but there isn't anything that can test for your experience and certainly nothing that can test how your experience applies to how you program/solve problems. Your experience (like the second post points out with commentary about solving problems and how you solve them, buy vs. build decisions etc.) is what makes you a truly 'good' programmer. Book smarts and understanding need to be there, but beyond that is what counts.

Is it good to be perfect?

So over on raganwald there was an interesting quote pulled from an article by Steve Yegge that I believe attempts to point out just how much he loves working at Google. The article goes on to essentially point out that Google seems to do everything right in terms of software development. The appropriate levels of documentation are always available, the correct unit testing and other information is always completed and as blasphemous as it may sound developers are given a bit of free choice and input into what it is that they are actually doing/developing. THIS sounds a little bit like a Utopian society of developers but is it really? Steve attempts to point out that the way Google has done it is part of a discipline he states:

"I don't think you can get that kind of software-engineering discipline without doing it right from the start, and creating a culture that enforces and reinforces that discipline as the organization grows."

While this may be true is it the reality? This statement would seem to exclude all those companies that didn't start out in the way prescribed. Does that make sense?

I think what the quote is missing is that most companies are in the software business because they have to be, not because that is their main focus or even their main business driver. Take for instance BigCo. BigCo has a range of products that it offers to people. The products that BigCo. offers are what drives its business. Now it just so happens that the products that BigCo. offers are sold through the web and that BigCo. also has a fairly large IT department managing all the systems that deal with the product that it sells. The process that BigCo. follows grew out of the product process not out of a software development process. Does that fact make what BigCo. does for software development inherently flawed - or better yet would it make the avg. software developer mad? I am going to guess that like most things some portion of the way software is developed would and some would not. In the end however I would argue that it is still possible for BigCo. to come to a similar nirvana as Steve has found in working for Google.

Companies grow and they change a great deal in their life times. Alot like humans grow from children into adults hopefully learning along the way. This learning process can be long and it can be arduous but it can be done. What I would argue that the change from child to adult software development requires is good people that are willing to help BigCo. move towards a vision of nirvana. I would argue that being the 'Perfect' development shop from the start may leave no room to grow, to change, to expand the horizons and most importantly it will lack the people with a questioning eye for how the process runs. Without the questions the process, no matter how good it is, may stagnate and start to blemish or tarnish and when it does - those developers living in nirvana won't know how to fix it because they have been too happy for too long.

Personal Hell (Working Fire)

So I was bouncing around the blog sphere this morning and located the following post on creating a personal hell and I have to say that I liked it quite a bit. Not only did it have a nice listing of classic development process mistakes but it went on to describe how he [the blogger] managed to get himself into a small circle of hell all its own by making some of the mistakes (OK making most of them) listed in the second post. Well worth a read if you do any sort of software development.

When is it time to go?

I am relatively young and I am certainly early in my "career" but I think that I have come to some fairly powerful conclusions for myself in the working world that I think might be valuable to share with others. I have spent some time bouncing around corporate space as well as some time consulting and have consistently come up against the following question: When is it time to bail out and find a new position?

The question is one of those questions that nags at you while you are working when things are not going quite the way you thought or if you are new in the position, not what was advertised to you when you got hired. This single question can actually drive you mad as you sit and contemplate it because the thought of changing jobs of potentially going for some period of time without an income is scary. It is nerve wracking to think that by leaving a job you might not be able to make it long enough to find a new one before money gets tight and things start to weigh on you like a 1000 lbs. gorilla sitting on your back. So - like the question said, when is it time to go.

What I have decided is that it is time to go when you can no longer bring anything to the table that will help the company. This ability to help can take many forms - it can be your feed back about what the processes that the company is using are doing, it could be simple things that would make things you do every day faster. Things that can help can even take the form of off handed comments to your boss about the people and processes that you work with twice a month. So - why do I think that this is the best indicator that it might be time to leave?

My biggest reason for this is thinking that a job is not just about money, a job is about your talents and doing something that you should (SHOULD) enjoy doing. Think about it - we spend a good portion of our days toiling in the jobs that we are in, WE SHOULD be happy while we are doing it. This is not to say that we will always be happy because the world is just not that way. It is more to say that we should endeavor to improve what we do for ourselves and the company. We spend too much time working as it is to HATE going in to work every single day. Each one of us has the power to effect change no matter how small that change is. We should use that power to improve what we do. When our voice ceases to be heard in any meaningful way it is most likely time to move on. Life and time is too short to feel undervalued or not valued at all.

Why? Because, the world is supposed to be constantly changing - when it stops changing something is wrong. Same thing holds true for jobs, when you can no longer improve the situations that you have to deal with it is time to find a new situation that you can apply your knowledge and experience to. If the current place of employment doesn't appreciate you then another one, somewhere will.

Not all of us are independently wealthy and not everyone has the drive to be the "Rich Dad" but all of us do have control over ourselves and what we do. Enjoy what you do - if you don't and no one is listening - move on. Its time to go.

My way or the highway (reprise)

In my original post My way or the high way I pointed out a bunch of reasons that a boss type person @ BigCo might be seen as a pain in most respects. It seems I was remiss and I left out one of the ways that this syndrome can manifest. This new way to manifest this syndrome is something like this:

It wasn't something I sanctioned or choose and as such should be turned off immediately.

Now there are certainly times where in a security conscious world that this particular decision making process might make sense. However, I am of the opinion that this process is more of a pissing match then it is really about solving problems.

My Reasoning: Bosses rarely if ever know what the developers need better then the developers do. So once the boss makes the "my way or the highway decision" to turn off something that the developers use and have made use of - the only thing she is doing is harming the organization that she counts on the most. Once might additionally argue that the farther up the "boss chain" or "chain of command" she sits, the less likely the decision is going to be based on fact or need and the more likely it is to be based on some wild personal feeling or desire to do something different.

In the end - I personally think it should be forbidden in companies for CIOs/CEOs to be making decisions about the individual software that developers 3, 4, 5, levels under them in the BigCo food chain use. They are just not in any position to make that decision wisely from where I sit.

Social Software Development

Working for a company, any company is often loosely based on your experience and the things that you as a worker are able to produce - at least this is what the companies would like you to think. Working for a company especially when you are a software developer or a project manager who oversees a software development project is so much more then more then the sum of the capabilities of the people on a given team.

Recently a friend of mine wrote a post on predicting the outcome of a software development project by objectively observing it. He posited that it should be possible to predict the projects outcome and if it is possible to do that, there should be a way of mechanizing the observances being made so that you could always accurately predict the outcome of a given software project. The perceived desire would be to be able to cut off a project that was destined to fail - long before it actually DID fail. What he found is something that I have often felt was at the heart of working for a company in general and more specifically and directly about software development as a whole.

What he found was that it was damn near impossible to mechanize the observations about a software development project and as such to use that information to predict the general health of said project. What he did find was that the social aspects, the interactions that the team was having and how they were having them was actually a far better indicator of the success or failure of a given project. More specifically he stated that the good Project Management of a project was about getting the people on the project who have information that can help you determine the general health of said project to give it up freely.

"Project management is a social problem. It is 99.5% about getting everyone who knows something about the state of the project to share what they know with everyone else. Getting all the relevant information is 99.5% of the problem, analyzing the information is 0.5% of the problem."

For some time now it has been my observation that working for a company and specifically doing software development is a social thing. You spend a great deal of time with the people that you work with, in some instances more time is spent with the people that you work with then you spend with your family at home - it should, due to that fact, stand to reason that what you do at work is going to have a social aspect to it. Beyond that you have to take into account that in order to like where you work you will also have to at least like "SOME" of the people that you work with. Add to the above facts that software development when you are part of a larger team is about information and its exchange you can not help but come to the conclusion that Project Management is about being social.

Think about it this way:
Software you are developing on your own, by yourself only requires that you know whats going on. Software developing in a team requires that the whole team know what is going on and that the information about whats going on is 'well' communicated to the company / project management.

I am sure you have all been on projects where this is not the case. Better yet you may currently work for a company that doesn't foster open and honest communication about project/development status. Did you feel that any of those projects where successes even if they actually did succeed? Or did you feel that the project somehow miraculously succeeded in spite of itself? I personally fall into the later case more often then not.

So whats the take away? Spend time in your company fostering open honest communication, either through tools (wiki, threaded forums, IM) or via personal interactions. Those open lines of communication can only help the situation not hurt it. If you squelch the lines of communication and ignore the social aspects of the working world you will almost certainly be destined for failure.

How much is too much / How Many is too many

If you have been working in a development environment that is bringing you down, how long have you been there? Better yet - if you have been working with a tool that is holding you back from getting things done faster how long have you been using it? Do you complain about the environment or the tool?

So just how many people does it take to screw in that light bulb? How many people collectively complaining about the same tool or process does it take before people take notice and attempt to change or remove the problems and obstacles?

Here is what I figure:
When the collective drag produced by utilizing a process or tool is SOOO great that you end up having to work around the work arounds just to get something done, it is time to give some serious consideration to changing the way you do things or the tools you use. Do not let it fester, if you do let it fester you too are to blame for the processes/tools continued existence.

Do yourself and others a favor speak up when you see these things [bad processes/tooling], louder, ... LOUDER - make your voice heard. Help you and your fellow developers out of the RUT and put a stop to bad process/tooling. Take a stand against the idea that if it was NIH its no good. Allow your processes and tools to support light weight ideas, and have a small impacts on your day. Allow those things to assist your efforts to get things done fast and in an efficient manner without repeating your self (DRY). After all this is why coders use IDEs right? They make things easier, right? if they didn't why use them? Take the democratic path - PROTEST bad process/tooling in earnest. BE THE CATALYST FOR CHANGE.

Get your "Code Goggles" On

Something has come to my attention recently and I think it was partially triggered by re-reading my previous post, why is it when people notice that the masses are unhappy with a direction or decision that they fight and kick and scream all the way through a change to make it better? Better yet - how is it that some people can not see the Code Smells that exist in a given code base.

I have now been working here at Big Co. for just over a year and have been quite astounded by the resistance to change within the IT organization. I have been equally astounded by the inability to bow down in the face of overwhelming opposition to an idea. In general I have my opinions about things. Lord knows I have my opinions - but when I am questioned on them and allowed to say my peace and the opposing side is allowed to say their peace I am comfortable then that all cards are on the table and the decision can be hashed out. I am also more likely at that point to allow my self to be trumped with a better or equally good idea. I think that this is a major part of a good give and take in life - let alone in the software development world. I also think that it is a good idea to be able to 'Let your Baby Go' and allow different ideas to take a seat and get some legs. To resist other peoples ideas or to resist the change that other people bring is bad practice and fails to value the things that a different perspective may bring.

Think of the ways that this particular resistance to change can manifest and you'll see what I mean:

1) The "CODE" Monger
This is the person who clings so tightly to the code that they developed that they will not allow anyone else to go in and make modifications/refactoring because the way they did it is SOOOO awesome that no one else could ever top it. GOOD GOD People, when you work for someone else your code is NOT your code - it is the companies code and other people by the very nature of a development organization will have to change and modify things you write. Just let it go.

2) I "Must" Be Right
Existing processes developed by other people in Big Co. start to take on water and look stale but the original 'designer' of the process refuses to modify or allow to be modified the original basis for the decision.

Both of these things fail to see the value in the people that work with you. Working with people like the above fails to acknowledge that other people have ideas too and that those ideas may have merit and they may not. In the end all being like the above does is diminish the Big Co. team as a whole because you have a small number of voices with little consensus driving the way things are being done. Actions like the above sew discontent and make people feel under valued, they are also very poisonous to the organization as a whole. Lets wake up, take the goggles off and take a good CLEAR look at what were doing to avoid being "That Co-worker" and have good clear conversation about where we want to go and why. Then lets go there together.

Change, not just the silver in your pocket

Change is not just the silver coinage in your pocket. Change is all about how you react to the world around you. We live in an ever-changing world, always moving, sometimes forward and sometimes back - but ALWAYS moving. Some people seem to thrive on this ever-changing environment eager not only to keep up but also to change along with the world - to learn, to grow, to expand with the world and its many MANY changes. Why is this so important?

Change is something that seems to happen with or without people involved. The world is spinning and things are changing without any effort from me right now at this very instant. This is important to note in terms of people because there seems to be a class of folk who stick too closely to the way things are 'Right now'. This class of people becomes mired in thinking about how things are rather then how things could be. They easily get caught up in the current and in some respects due to that are missing the boat so to speak. They are missing the boat because this group of people seems to always cling to the past and to a routine without accepting or at least acknowledging a modicum of change in their day-to-day, month to month, year-to-year life. What is the draw back to thinking like this - to being someone who doesn't look or acknowledge change? The draw back is the rigidity that it brings to a personality. The inability to accept new things, new people and new processes is the draw back.

I have long thought that being on this planet is all about learning and expanding my personality as well as my spirituality. I see an inability of people to accept change as not acknowledging a level of lifetime learning. I look at it as being 'stuck' with an almost 100% inability to move forward. Now I know that some people are saying that it is hard enough just to live in the 'now' or to live in the moment. Granted the world is moving much faster these days and things are operating at a much quicker pace now then they were just 10 years ago. I get that and I certainly feel that same way. I do not believe however that this gives people a free pass to stand still and not grow and learn as things change. Living "in the moment" means a little more then just being present - it means walking away from the moment with something more then when it started. It means accepting some small change or large change that occurred as a result of that singular moment. Do not let yourself fall into a rut - Strive to make your world what you want it to be. If you already accept change easily then put energy into education, learning - and expanding. Help people embrace change rather then fear it. If you are one of the people that gets stuck then try to strive to listen - there is probably someone who does not fear the change trying to help you to move forward and expand your knowledge. There is probably someone standing next to you right now with their hand outstretched inviting you a hand out of your rut.

Treating people with 'respect' - id10t errors.

I recently read a post that has peeked my interest. Dan over at It ought to be simple posted a write up on IT and how pretensious IT people can be when it comes to dealing with users (or if you are going to be pretensious lusers).

I have to admit that I tend to think he is hitting the nail on the head with this one. In the world you can run into a great number of people some of them good and some of them bad. Some of these people that you run into are people who will have some impact on you and your life. Be they bosses, wives, etc. this second group of people is usually where I classify the users of IT. They have some impact on the life of an IT person in the sense that their feed back and questions and comments more often then not turn into bugs, requirements or reprimands for doing things BADLY in IT.

This doesn't however give IT the right of way to call them idiots or to beraid them when they do something in the system that the system let them do that they really shouldn't be doing. This highlights the problem at its heart for me. IT is really about servicing the users at its core. These users are really what keeps us all in jobs and in business doing what we love, yet at every single turn we treat them as lower then low. This in turn means that IT is not acting professionally as Dan points out. More specifically that IT is not accepting responsibility for the things it does/develops. IT folk attempt to protect themselves by saying things like "That is the way the requirements were defined, blah blah blah" rather then standing up and saying that they didn't think that a given requirement was a good idea and fighting for it to get changed before it gets implemented. If it does get implemented taking some level of responsiblity for it being that way rather then foisting that burden off on someone else. We try to find every way in which to coat ourselves in Teflon and make comments about how we do our job slide right off. This ignors our part and makes us as bad as the people we are denegrating in the first place.

Complacence is death: If we sit idly by and watch thing happen and poke fun at them while we do we really are no better then a good portion of the world watching the Nazis condem an entire race to death. While that might seem to be a harsh comparison - think about it, by calling the users idiots and demeaning them making them part of a "lessor" class and IT as part of a "higher" class we are setting ourselves up for a comparison as such. If that comparison is too strong for you, how about IT is white and users are black? Does that help?

Where we go from here: In the end we have to treat those people like we would want to be treated. I too have worked on both sides of the fence and been in IT as a developer of systems and software and as a user of a different group of IT in terms of machines and infrastructure. We all have a choice of helping, and accepting responsibility in some part for how things are, and like Dan says looking at each call into the IT department as a chance to make something better... to improve the interaction between the users and IT rather then denegrate them and make them into something they are not.

UI Refactoring

There has been a bit of discussion on the topic of simplicity lately. Joel has talked about simplicity in terms of features and the simplicity of not having too many choices to make when taking/making a simple action in a user interface (or at the very least taking/making what on the surface 'seems' like a simple action). This topic of Joel's touched off a response in the form of an explanation from the MS camp that he was lambasting. He also recently expounded on elegance and what makes something elegant. I believe that these two things are intertwined and have some serious impact on certain people when it comes down to what makes up a good user interface design.

Programming as we already know is hard but the user interface should be easy right? I mean seriously we all use them every single day and we know what doesn't work from what does right? One might take those questions to mean that I personally think that every single person who has ever touched a program in their life should be able to design an effective interface from the ground up. Most programmers know from experience that this is not the case. However - back to our original topics of simplicity and elegance.

Joel rightly points out the interfaces should be simple. This means easy - or almost intuitive to use. This does not mean that the interface should not contain as many useful features as it can support. What it means instead is that when you go to do something with your whizzbang new toy, gadget, program, computer thing... it should work in a straight forward and intuitive manner. NOW - it is that last bit "intuitive" that is the hard part about software UI design. This is even more true when you consider that UI design, like software programming, suffers from some of the very same problems. The Overall UI design picture can get bit rot and get old over time. So the original SIMPLE and ELEGANT design (i.e. it just works and it does just what it is supposed to do) can become cluttered, annoying, and just plain bad the longer it sits out there. This "bit rot" effect can be exacerbated by not giving the design and new features of the UI a good thought process when a group of programmers is attempting to add new features.

In the programming world we combat this problem by continuously refactoring the code. This is not the one liner spot refactoring that can be done from within your typical IDE. Nor is this the type of program refactoring that consists of variable renaming for the readers sake - THIS type of refactoring is a critical look at what a program was for, what it is for now, and what it will be for a few days/weeks/months from now. This allows the programmer to mold the program like clay to match the needs as they expand. What appears to be missing in most software shops is a similar process for the user interface. User interface deserves the same attention as "does the code do what it is supposed to" - why you might ask? the answer should be simple, the interface is what people see first - it is the first impression, the first experience with what and who you are if your job is creating a user interface to ANYTHING that has to drive underlying software processes. More importantly the simplicity and elegance of solution need to be inbred into both the software and its user interface and while a single design may have been just fine when you started it always deserves to be revisited. UI design like software should be ever changing or at the very least being continuously reviewed to make sure that it still meets the needs, is simple and elegant to perform the job at hand. IF the UI you have now is neither of those things - you may be missing, at the very least, half of the software development equation.

My way or the high way

It really has just been one of those days. In my previous post I did a bit of ranting about why companies always have to pick the hard way to do things. This time around I thought I would attempt to address one of the things that really gets on my nerves, the "I am the boss so you'll do what I say" syndrome as I like to call it.

This topic has come up for me a few times in my career so far and it seems that in my current position at "Big Company" I will be experiencing it more and more. The syndrome usually involves your boss or your bosses boss and works something like this:

1) A pet project of the 'boss' has been created
2) This pet project is not part of the current development line(s)
3) The 'boss' makes a request to get this pet project in 'Right away'
4) This 'right away' flies in the face of reason
5) This 'right away' forces other things out of the way.

The reason that I think these types of things are especially bad is for the 'flies in the face of reason' of #4 stated above. In my current case it is a pet project of the 'boss' that has not been tested or reviewed and the boss would like this change implemented in a very short time frame. Why does this bug me so much? Well, "Big Companies" like to tout that they are secure and that they have process (as in my previous post) and that the software that is developed at "Big Company" is of the tippy top quality. However, when pet projects come up all of these procedures and policies and so on seem to go right out the window. In the end this means that the software is of a lower quality because changes are rushed in, they are not reviewed and vetted properly and as such also have a high probabilty of having some security issues and other bugs (even more so when you speak about doing web development). The other reason that this "I'm the boss so you will do what I say" thing bothers me so much is personal.

When I was growing up I came to believe that the saying that I should "Respect My elders" was bunk not because the thought itself is bunk but more because of the way most of my "Elders" said it. They all seemed to say this line as if I should respect my "Elders" because they are old. I patently disagree with the statement when stated in this way. I, rather, agree with the statement when it is taken to mean that I should respect the knowledge that my "elders" have due to their being on the planet longer. I additionally treat this not as a given but something that you have to prove to me that you have. This is why it has always bothered me to hear people in positions of power say "You should do this thing A because I said you should", or "Jump THIS High because I am your Boss." Both of these statements do nothing to solidify my belief that they know what they are doing but rather does more to solidify that they are absolute morons that got where they are not by being bright - but by being ruthless and nasty and always getting their way because they can.

So - like my previous post, why does it have to be "My way or the high way", in my personal experience the adage "You catch more flies with honey" is more applicable. Choosing to work in the system as defined and to work WITH your employees to make decisions is more beneficial to both their growth, your leadership as a boss - and the "Big Company" as a whole.

Why do they always pick the hard way...

I have started to read a number of blogs on the internet having to do with software development. Some have been better reads then others, but recently a friend of mine made a post on Business programming not being that hard I began to think about this in the car on the way home and I felt inspired to write something in a blog of my own.

I started to wonder about why Big Business seems to consistantly strive to make things as hard as they can on developers in the name of progress? Just about every largish company that I have been associated with in my fairly short career has touted some process or methodology that they follow that helps them to produce high quality software in a highly repeatable fashion with quick turn around. Can the management of these companies really be that daft? Do they walk around with blinders on all day long thinking to themselves what a great thing they have laid upon the feet of the software developers that work for them?

Process for the sake of process doesn't do anything to help the software developer and more often then not it seems to get in the way. My life examples are things like CMM (Capabliity Maturity Model) and Prince II and a few others that have had less defined processes that they would choose to follow (Waterfall and others). These things are all fine and good in their own right - but they MAKE THINGS HARD! In some cases unduely hard.

Why do these processes make things hard - they make things hard because every single one of them get in the way of doing the primary job of a programmer. What is that you might ask ... PROGRAMMING! Each one of these items requires gobs and gobs of documentation, time tracking, etc. etc. etc. which detracts and distracts from the job at hand ... Getting the code down and into source control so that someone can take a look at it and say "Yeah" or "Nay" and then more code can be written or modified to bring the end result in line with some persons individual/business requirements.

Knowing this - why is it so hard for businesses to attempt to define a process that does just that - allow the programmer to work with the business or a smallish group of people to allow the code and small amount of documentation to stand on its own? Why do businesses cling to making things as hard as humanly possible on the developers and the staff that surround them? Why do they all cling to the idea that putting these heavy processes around what programmers do is somehow an improvment on the way things work?

I understand that there have to be some controls, Change control is a good example. I also understand that there has to be some common understanding of an 'overall' process so that more then just the developer and a business person can understand whats happening and when, but why such heavy handed processes and procedures?

Now I can hear some people saying "Why not adopt an agile approach?" This is all fine and good but one can not look at things like the agile methodologies that have sprung up of recent as a Silver Bullet solution to the 'old' way of doing software development processes. However, what still befuddles me is why companies find it so hard to take the best of both worlds - the bits of one methodology that aid rather hinder and mash them together into their own way of doing things. I guess in the end - blindly following a process for the sake of the process is easier then taking the road less traveled and actually developing a process that works.