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.
Sunday, November 25, 2007
Tuesday, November 13, 2007
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.
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.
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.
Subscribe to:
Posts (Atom)
