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.