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.
Thursday, June 28, 2007
Monday, June 25, 2007
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.
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.
Friday, June 15, 2007
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.
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.
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.
Subscribe to:
Posts (Atom)
