I’ve been thinking more about the ramifications of our design decisions lately. I think it’s because we had a less than enjoyable call with a client the other day. Currently we’re working on a system that will be added to the client’s suite of tools which support their business processes. Since we’ve never worked with these clients before everything about the new system and their older systems is new to us. The result is that we keep coming across current and past design decisions that are less than optimal, to say the least. In some cases, they’re down right bizarre. So, like any good developers, our first reaction is always to oil that squeaky wheel.
However, time and time again we keep running into stubborn clients who like their wheels to squeak. Maybe the sound helps them sleep at night, like some other worldly form of white noise. This got me thinking, are people so afraid of change that they’d rather put up with an annoyance or, in this case, a less than optimal process rather than learn another one.
I remember when I first installed Windows 98; a good decade ago now. I was greeted by a helpful little popup dialog that informed me I could click on the Start button to access all my programs and files (On a side note, every time I’ve reinstalled Windows since then I still get greeted by this popup. It’s getting less and less helpful each time). This worked well for the first few years, until J.P. Boodhoo introduced me to Launchy. Now, I never click on the Start button. My desktop is clear of icons; except for anything I am working on at the time. I don’t display the Quick Launch bar anymore; it’s slower than just using Launch.
Even when I change environments and use my Mac, I enjoy the Dock control. Really, I’ve learned that the Start button is probably the least efficient way of accessing anything. Even a larger number of the different Linux distributions put that little button down in the corner so users will get that warm fuzzy windows feeling. Even in Windows 7 we are still presented with the Start button. Sure, when you click it the menu is slightly different, but it’s still the same one stop button shop. I’m even willing to put money on the assumption that the touch screen panels aboard the Starship Enterprise are going to have little tiny Start buttons down in the left hand corners.
When you think about it the Start button, the Dock, Launchy, and the command line; you realize they all do the same thing. They each give you access to your programs and files; each having its own level of overhead. In the computer world, people learn one way to do something and stick with it. Does this really translate into the real world though?
This weekend I need to borrow my parents van. Driving it’s a totally different experience from driving my compact car. All the buttons and knobs and levers are in completely different spot. I don’t think anything other than the wheel and the pedals are in the same location between the two. I’m really not sure if either layout is more efficient, but I do know they’re quite different. None of this stops me from driving it. I don’t even think about it. I just take a second or two to acclimatize myself to where everything is and how to do my normal driving tasks, and away I go.
However, you throw a Windows user into an OS X environment and they are lost. Even though the use cases for both systems are the same, when you introduce technology, people just seem to be unable to remap their processes. I bet if I replaced the steering wheel in your car with a joystick, you’d figure it out pretty quick. But if I replaced your Start button with something a little different, how would you react?
The scary conclusion from all this is that there is a good chance that we are going to be forever shackled to the design decisions of the past; the good and the bad. My keyboard still has a Scroll Lock button, for example, even though I’ve never used it and really have no idea what it does. I just pushed it to see what would happen. It turned on a green LED on my keyboard. Well, there you go, the scroll
Friday, March 6, 2009
Tuesday, March 3, 2009
Welcome to the Team
There’s been a lot of talk lately about hiring and retraining. So, I’ve put together my list of hiring priorities:
1. Experience – People who have had experience developing can be judged based on that experience. Just talking to these people and looking at what they have done will give you a good idea as to their fit. Most likely these people will have something to bring to the group; however, their past performance should be verified. A simple FizzBuzz like test should be enough to weed out the wolves in developers clothing.
2. Training – People who have had formal training but lack real world development experience have, at the very least, had exposure to software development. At the very least, these people have been trained, tested, and voluntarily – most likely - attended training sessions. Similarly, a simple FizzBuzz like test should be used to see how much of the training actually sank in.
3. Initiative – People who show initiative, either by doing independent learning or attending User Groups or Learning Lunch sessions, have shown interest in development and have personally put the time and effort into gaining insight into and skills in the field. These people should definitely be given the chance to prove themselves. A temporary or job shadowing position would allow them to experience what development is like in a real world setting and allow us to asses their level of fitness.
4. Aptitude – Some people are natural problem solvers. People who show a natural aptitude to solution development should be given acting positions, allowed to take formal training, or given direction / mentoring to see if they really could – or even wish to – become developers. Simple tests are basic problem solving skills, comfort with technology, or formal aptitude tests.
5. Interest – And some people are just dev-curious and it wouldn’t hurt to take formal training, or given direction / mentoring to see if they really could – or even wish to – become developers.
6. None of the above – If someone hasn’t displayed or doesn’t posses any of the above, then I really can’t see a valid reason to bring them into the group, either permanently or as an acting. These are people who are attracted to the trend or the pay or just see development as an opportunity to brown nose their way up the ladder.
I get worried when people who fall in the bottom two categories start to work their way into a development ream. Mainly because I’m not really sure what we’ll do with them, but also because they are stealing a seat from someone in the top two categories.
1. Experience – People who have had experience developing can be judged based on that experience. Just talking to these people and looking at what they have done will give you a good idea as to their fit. Most likely these people will have something to bring to the group; however, their past performance should be verified. A simple FizzBuzz like test should be enough to weed out the wolves in developers clothing.
2. Training – People who have had formal training but lack real world development experience have, at the very least, had exposure to software development. At the very least, these people have been trained, tested, and voluntarily – most likely - attended training sessions. Similarly, a simple FizzBuzz like test should be used to see how much of the training actually sank in.
3. Initiative – People who show initiative, either by doing independent learning or attending User Groups or Learning Lunch sessions, have shown interest in development and have personally put the time and effort into gaining insight into and skills in the field. These people should definitely be given the chance to prove themselves. A temporary or job shadowing position would allow them to experience what development is like in a real world setting and allow us to asses their level of fitness.
4. Aptitude – Some people are natural problem solvers. People who show a natural aptitude to solution development should be given acting positions, allowed to take formal training, or given direction / mentoring to see if they really could – or even wish to – become developers. Simple tests are basic problem solving skills, comfort with technology, or formal aptitude tests.
5. Interest – And some people are just dev-curious and it wouldn’t hurt to take formal training, or given direction / mentoring to see if they really could – or even wish to – become developers.
6. None of the above – If someone hasn’t displayed or doesn’t posses any of the above, then I really can’t see a valid reason to bring them into the group, either permanently or as an acting. These are people who are attracted to the trend or the pay or just see development as an opportunity to brown nose their way up the ladder.
I get worried when people who fall in the bottom two categories start to work their way into a development ream. Mainly because I’m not really sure what we’ll do with them, but also because they are stealing a seat from someone in the top two categories.
This Old Code
When faced with something new, it’s usually comforting to equate it to something old and familiar. This is fairly commonplace in the world of software development. It’s much easier for programmers to think of software in the terms of things that have been around much longer. This is the root of our association of software development as an engineering discipline. These analogies can be very helpful in allowing us to understand the often overly complicated world of software development, however, when these analogies prove false, they can lead up down some very dangerous paths.
Take, for example, the idea of code maintenance. The idea that code needs maintenance comes from our associate of software development to any of the many historical engineering disciplines. Civil engineers, for example, build buildings which then require constant upkeep to keep them clean and stable. Mechanical engineers build complex machines that need to be oil and tuned so they don’t seize up. Electrical engineers build circuits that, over time, heat up and deteriorate. At a very basic level it makes perfect sense to associate the development of software with the building of a house, they both revolve around the creation of something new from basic building blocks.
So, that being said, let’s try to invasion our software system as a house. Our house needs constant maintenance. The floors must be swept, the driveway sealed, and the garden weeded. In fact, if we had the funds, it would be beneficial to have a gardener on staff all year round to mow the lawn, pull up weeds, trim the trees, and water the flowers. Someone needs to do all these little tasks which are required to keep our garden growing. Along the same lines, who among us would frown at the idea of a live-in servant who would dust and clean and keep every part of our house in near immaculate condition? As with any sensible idea, however, we as the owners of software systems, or house in this case, often take this idea to the radical extreme.
We have a plumber around the house at all times in case we spring a leak. We have a carpenter on hand in case a neighborhood kid sends a ball through our window. We have an electrician on the books in case someone blows a fuse plugging in too many Christmas lights. The end result of this being that we now have a huge staff that we have to pay, even when they’re not doing anything. Not only that, but they’re always in our house. Even the gardener, who’s very busy during the summer, has nothing to do in the winter. So we find other little tasks for them to do and they end up spending their free time making little enhancements to our house. They add new faucets, or new trim, or maybe a few dimmers. They’re not needed, but since we have these people in our house, we might as well use them.
This is the view we have of software. We need a dedicated database admin just in case the database goes down. We need a programmer or two just in case some weeds start to grow in the code. We need a few testers around to ensure the logic hasn’t started to rust. However, we’re ignoring the core truth here; that code does not need maintenance. It does not rust, it does not decay, it does not degrade, weeds do not grow in it, and therefore it does not need maintenance. There are only two ways an error can occur in code. First, you put it there yourself. As hard as it is to admit, we don’t always get it right the first, or second, time. Or second, an external dependency of the system has changed. It might be a service we rely on, it might be the hosting environment, or it might be as simple as your disk has run out of space. However, the key point here is that something must change; otherwise the code is just going to keep running as it’s always run.
So, why do we have this fallacy of code maintenance? First, we’re building on an inaccurate analogy. Code, unlike the physical world of house and cars and hardware, doesn’t deteriorate over time. Second, the broad heading of maintenance gives people the leverage to have their very own gardener, servants, plumber, carpenter, and electrician at their beck and call. And, honestly, who can blame them, it’s much handier than having to call a plumber in the middle of the night because you have a leak As long as the process allows this, you’d be silly not to take advantage of this and safeguard yourself this way. Third, we are afraid that if our pipes ever do spring a leak, we won’t be able to find a plumber. So we keep one around just in case.
So why don’t we just have a plumber in every house? First off, it’s also not very cost effective to have a skilled resource assigned to a project, just in case something goes wrong. The lost cycles of productivity are astounding. Second, it’s also not fair to all the other people who need a plumber. Plumbers do not grow on trees. They are a limited resource and must be shared. Third, having your plumbers sitting around all day just waiting for a problem to occur does nothing for their skill sets. They will become out of practice and will never gain new and valuable experience. Fourth, and most importantly, you are condemning your plumbers to careers of boredom and stagnation. Who would want to work for such an organization?
So how do we deal with this problem? Well, first off, we need to stop believing that code needs maintenance. Yes, maybe the colour of the paint should change, and the drapes are outdated, and the car runs like a pregnant yak. But that’s okay, it all still works. And if you want to change it, demonstrate the business value that our changes will add and it might get funded. Next, we need to give up on the idea of our small little empires and embrace the idea of a commonwealth of professionals. We can’t all have our own personal household full of servants to do our bidding. If your changes have real business value, then you should be able to justify your changes as real, fully fledged, projects. And finally, if you spring a leak, call a plumber; don’t have him sitting around all day. Have a service level agreement in place that if something serious happen, you can get your staff. It may slow down system lower on the totem pole, but that’s why we have priorities.
Most important of all, be happy. You live in a house whose foundation will not rot, whose roof will never leak, and whose lawn never needs to be mowed. And, as long as the neighborhood kids don’t put a ball through your window, you can live happily ever after.
Take, for example, the idea of code maintenance. The idea that code needs maintenance comes from our associate of software development to any of the many historical engineering disciplines. Civil engineers, for example, build buildings which then require constant upkeep to keep them clean and stable. Mechanical engineers build complex machines that need to be oil and tuned so they don’t seize up. Electrical engineers build circuits that, over time, heat up and deteriorate. At a very basic level it makes perfect sense to associate the development of software with the building of a house, they both revolve around the creation of something new from basic building blocks.
So, that being said, let’s try to invasion our software system as a house. Our house needs constant maintenance. The floors must be swept, the driveway sealed, and the garden weeded. In fact, if we had the funds, it would be beneficial to have a gardener on staff all year round to mow the lawn, pull up weeds, trim the trees, and water the flowers. Someone needs to do all these little tasks which are required to keep our garden growing. Along the same lines, who among us would frown at the idea of a live-in servant who would dust and clean and keep every part of our house in near immaculate condition? As with any sensible idea, however, we as the owners of software systems, or house in this case, often take this idea to the radical extreme.
We have a plumber around the house at all times in case we spring a leak. We have a carpenter on hand in case a neighborhood kid sends a ball through our window. We have an electrician on the books in case someone blows a fuse plugging in too many Christmas lights. The end result of this being that we now have a huge staff that we have to pay, even when they’re not doing anything. Not only that, but they’re always in our house. Even the gardener, who’s very busy during the summer, has nothing to do in the winter. So we find other little tasks for them to do and they end up spending their free time making little enhancements to our house. They add new faucets, or new trim, or maybe a few dimmers. They’re not needed, but since we have these people in our house, we might as well use them.
This is the view we have of software. We need a dedicated database admin just in case the database goes down. We need a programmer or two just in case some weeds start to grow in the code. We need a few testers around to ensure the logic hasn’t started to rust. However, we’re ignoring the core truth here; that code does not need maintenance. It does not rust, it does not decay, it does not degrade, weeds do not grow in it, and therefore it does not need maintenance. There are only two ways an error can occur in code. First, you put it there yourself. As hard as it is to admit, we don’t always get it right the first, or second, time. Or second, an external dependency of the system has changed. It might be a service we rely on, it might be the hosting environment, or it might be as simple as your disk has run out of space. However, the key point here is that something must change; otherwise the code is just going to keep running as it’s always run.
So, why do we have this fallacy of code maintenance? First, we’re building on an inaccurate analogy. Code, unlike the physical world of house and cars and hardware, doesn’t deteriorate over time. Second, the broad heading of maintenance gives people the leverage to have their very own gardener, servants, plumber, carpenter, and electrician at their beck and call. And, honestly, who can blame them, it’s much handier than having to call a plumber in the middle of the night because you have a leak As long as the process allows this, you’d be silly not to take advantage of this and safeguard yourself this way. Third, we are afraid that if our pipes ever do spring a leak, we won’t be able to find a plumber. So we keep one around just in case.
So why don’t we just have a plumber in every house? First off, it’s also not very cost effective to have a skilled resource assigned to a project, just in case something goes wrong. The lost cycles of productivity are astounding. Second, it’s also not fair to all the other people who need a plumber. Plumbers do not grow on trees. They are a limited resource and must be shared. Third, having your plumbers sitting around all day just waiting for a problem to occur does nothing for their skill sets. They will become out of practice and will never gain new and valuable experience. Fourth, and most importantly, you are condemning your plumbers to careers of boredom and stagnation. Who would want to work for such an organization?
So how do we deal with this problem? Well, first off, we need to stop believing that code needs maintenance. Yes, maybe the colour of the paint should change, and the drapes are outdated, and the car runs like a pregnant yak. But that’s okay, it all still works. And if you want to change it, demonstrate the business value that our changes will add and it might get funded. Next, we need to give up on the idea of our small little empires and embrace the idea of a commonwealth of professionals. We can’t all have our own personal household full of servants to do our bidding. If your changes have real business value, then you should be able to justify your changes as real, fully fledged, projects. And finally, if you spring a leak, call a plumber; don’t have him sitting around all day. Have a service level agreement in place that if something serious happen, you can get your staff. It may slow down system lower on the totem pole, but that’s why we have priorities.
Most important of all, be happy. You live in a house whose foundation will not rot, whose roof will never leak, and whose lawn never needs to be mowed. And, as long as the neighborhood kids don’t put a ball through your window, you can live happily ever after.
Subscribe to:
Posts (Atom)
