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.
Subscribe to:
Post Comments (Atom)
1 comment:
Of course, sometimes it's difficult to convince Big Co. that these fundamentals really will help (after all, they think they're already going as fast as possible). This is where it can be helpful to set up a small example or a "skunkworks" project.
At the company where I work I know some people had spent years advocating the need to introduce some agile development techniques, with almost no success. Then a new manager came in and set up one team actually DOING agile work. Shortly thereafter, the company began to see the light and started to use agile techniques in many parts of the organization (not yet all).
Post a Comment