from: http://blog.360.yahoo.com/blog-TBPekxc1dLNy5DOloPfzVvFIVOWMB0li?p=967
"Before going on I should like to explain why I may have objections to "superfluous features". Suppose that a machine contains a certain feature and that I can show, for instance, that it is impossible to use it intelligently or that its use gives rise to undesirable programming conventions; suppose furthermore that the defender of the design agrees to my objections but defends the feature by pointing out that, if I do not like the feature, I do not need to use it, implying that no harm can be done by something "extra". In that stage of the discussion I shall stress that the design would have been better without the feature under discussion. If it is impossible to use it intelligently every effort to do so is spoilt and the programmer would have been better off without it. If its use gives rise to undesirable programming conventions, also in that case the programmer had better ignore the feature completely."
I wrote a post a while back on some things being overly complicated in which I was talking about some new features being introduced into the java language. I think the above quote rather proves my point. If by adding a new feature you are claiming that only a select few people would be capable of using it and those who don't know how or wouldn't use it - Shouldn't, then you are adding something that should be considered superfluous. If the feature is impossible to use well or as intended - Why have it at all?
Monday, March 23, 2009
Agile, Agilsts and philsophy
Being Agile
So I recently read an interesting article on the decline and fall of the agilists. I have to admit that it was an interesting read and it was not what I was expecting at all. I had decided on clicking the link that I was heading to read an article that was lambasting agile as a whole, and in specific the people who supposedly support and enable people to be agile in their enterprise. What I got was different. What I got was a point of view on people being far to rigid in their ideology, the agilists, the evangelists (supposedly) of the agile software development 'movement'. The point of view was decisive and accurate in my opinion, but not because agile is anything specifically different or the people who support it are any different - but because what I get out of it is an equation of an agilist to a terrorist or other extreamist.
Becoming an avid agile supporter
Over the years I have become a rather avid supporter of the agile methodologies. Scrum, XP and a few others have become the ways and methods that I would naturally choose to use when I attempt to do software development. These mthods are also the way in which I would hope that the business that I work for would choose to do their software development work. This of course is not always the case. Like most people I have worked for companies that have waterfall methodologies or other ways to do software development. These methods in some ways work for the companies that have adopted them. Sometimes they work very very well for those companies. They get alot done with their waterfall systems and feel that they have accomplished alot. It is my beliefe that even those companies could get more out of using agile methods. This makes me a supporter of agile, but it doesn't yet make me an agilist. It means that I would choose to attempt to talk the people I work with into giving agile methods a try - But I am not going to dictate that they need to do XP to be agile. More it is to describe that I am going to attempt to let people know what I have seen work in other places using my experience to try and allow a change to occur in the company. One that hopfully will get them to recognize a benefit.
The agilist in hiding
Does the desire to only use Agile methods make me an agilst. Possibly, but what I think differentiates me from the agilsts that are pointed out in the article is that I don't support doing agile in one set and unchanging way. One of the tenants of the agile movement is that the process has to be about the 'people' involved - the individuals and interactions before the processes and tools. You always have to start with the people. You have to look at what the people do, see how they move day to day and attempt to help them along a path. as an agilst I attempt to provide guidance and support for any given company finding their 'own' path. In a number of cases these choices will be what I recommend - but in a great number they will not. These other company(s) will need help finding their own path. This is when the agilist must become a person that helps to maintain the 'spirit' of the manifesto... attempts to provide guidance for the decision making process rather then dictating that things be done in a specific way.
Being an agilst is all about the philosophy
Being an agilist is all about the philsophy held - its all about the people involved. Its about nurturing the good processes and tools in support of the people and interactions. Being an agilist is not dictating that it must be some 'ONE MAGIC' way. People that attempt to make being agile all about being one specific way are looking for a magic bullet (a silver one perhaps). In the end however we all know there isn't one. Development of software is sufficently chaotic that having bumpers is better then knowing the one true path. Having guidlines rather then mandates... having a person who is willing to guide rather then dictate can be helpful. The aim is to move forward the best way we know how given the situation, I personally believe that being an agile organization is important to 'grow' how software is developed. I am an agilist in my heart, but certainly not the one that Mr. Appelo describes. I hope never to fall into that trap and become a cult leader for agile.
So I recently read an interesting article on the decline and fall of the agilists. I have to admit that it was an interesting read and it was not what I was expecting at all. I had decided on clicking the link that I was heading to read an article that was lambasting agile as a whole, and in specific the people who supposedly support and enable people to be agile in their enterprise. What I got was different. What I got was a point of view on people being far to rigid in their ideology, the agilists, the evangelists (supposedly) of the agile software development 'movement'. The point of view was decisive and accurate in my opinion, but not because agile is anything specifically different or the people who support it are any different - but because what I get out of it is an equation of an agilist to a terrorist or other extreamist.
Becoming an avid agile supporter
Over the years I have become a rather avid supporter of the agile methodologies. Scrum, XP and a few others have become the ways and methods that I would naturally choose to use when I attempt to do software development. These mthods are also the way in which I would hope that the business that I work for would choose to do their software development work. This of course is not always the case. Like most people I have worked for companies that have waterfall methodologies or other ways to do software development. These methods in some ways work for the companies that have adopted them. Sometimes they work very very well for those companies. They get alot done with their waterfall systems and feel that they have accomplished alot. It is my beliefe that even those companies could get more out of using agile methods. This makes me a supporter of agile, but it doesn't yet make me an agilist. It means that I would choose to attempt to talk the people I work with into giving agile methods a try - But I am not going to dictate that they need to do XP to be agile. More it is to describe that I am going to attempt to let people know what I have seen work in other places using my experience to try and allow a change to occur in the company. One that hopfully will get them to recognize a benefit.
The agilist in hiding
Does the desire to only use Agile methods make me an agilst. Possibly, but what I think differentiates me from the agilsts that are pointed out in the article is that I don't support doing agile in one set and unchanging way. One of the tenants of the agile movement is that the process has to be about the 'people' involved - the individuals and interactions before the processes and tools. You always have to start with the people. You have to look at what the people do, see how they move day to day and attempt to help them along a path. as an agilst I attempt to provide guidance and support for any given company finding their 'own' path. In a number of cases these choices will be what I recommend - but in a great number they will not. These other company(s) will need help finding their own path. This is when the agilist must become a person that helps to maintain the 'spirit' of the manifesto... attempts to provide guidance for the decision making process rather then dictating that things be done in a specific way.
Being an agilst is all about the philosophy
Being an agilist is all about the philsophy held - its all about the people involved. Its about nurturing the good processes and tools in support of the people and interactions. Being an agilist is not dictating that it must be some 'ONE MAGIC' way. People that attempt to make being agile all about being one specific way are looking for a magic bullet (a silver one perhaps). In the end however we all know there isn't one. Development of software is sufficently chaotic that having bumpers is better then knowing the one true path. Having guidlines rather then mandates... having a person who is willing to guide rather then dictate can be helpful. The aim is to move forward the best way we know how given the situation, I personally believe that being an agile organization is important to 'grow' how software is developed. I am an agilist in my heart, but certainly not the one that Mr. Appelo describes. I hope never to fall into that trap and become a cult leader for agile.
Sunday, February 1, 2009
Process, progress and equality
So a friend of mine Mr. Fury recently wrote a little post on "Process" (Yup, thats capitol P process). Specifically, since he and I work for the same Big Co., we was writing about a wonderful framed master piece that hangs on a number of walls at Big Co. This art piece, which he points out, is meant to be inspiring and up lifting is a bit off the mark and is a bit mocking rather then inspiring and uplifting. This picture says simply "Process = Progress", I think attempting to indicate that we are not moving forward @ Big Co. unless there is a process in place. It may also indicate that progress can not be measured without a process - but I am not sure that is the direct meaning.
Now - I admit, that I share some of the sentiment that was expressed by Mr. Fury on this one: process = progress seems to be a little off the mark in the situation that he describes. To the point where for a little while when I would see this supposedly inspirational picture hanging around our building I would take a black Dry Erase marker and add the programmers negation to it ("!=") placing an exclamation mark in front of the equals sign. Thus changing the equation from a equals to a "not equals". However as I think about this situation even more, even the not is a little overkill (just moving to the other extreme).
The Bad
Process used as a shield against new work or used as a way to send people into a wait state - or cause them to circle because they have not paid homage to the process is using it in a way that it should never be intended. Those people are using process to attempt to slow things down because they are overloaded, overworked or just plain a pain in the ass. In any case - it certainly does not equal progress, quite the opposite in fact.
In this sense - I agree with Mr. Fury because he pointed out in his case that the process was getting in the way. In fact it was adding additional time and drag to what he was attempting to get done. In a number of ways this is doing process for the sake of doing it and not because it is adding value to the job or the work being done. Sometimes it is tolerable to allow process to add a 'factor' onto work being done, but when the additional work being done really feels like it is busy work, or work gone to waste - that process should be dropped or changed it is no longer achieving whatever the process' original goal was.
I liken this bad state of process to the current state of Unions. When you are 'not permitted' to do something as simple as plugging your laptop into a network port in a building because that is a 'union job', that is process for the sake of process and is just plain stupid.
The Good
Process that helps communicate amongst many and various groups inside of Big Co. This is the equality that I think the picture is attempting to draw out. As a company grows it will have need to attempt to keep a bunch of separate units all on the same page. The increasing size of any company makes this increasingly difficult. In this case a little process can help and be beneficial. The caveat that I make is that the process needs to be defined and agreed to by both sides of a given communication and has to be helpful to them both. This decision to add process then needs to be revisited on a semi-regular basis to verify that the process has not grown stale and the need for it long since gone away. Only here do I think that process = progress - using process to help progress.
Overall - I am not sure the direct equality makes sense even with my definition for "The Good". A little process doesn't hurt where it makes sense - but when the process goes bad or is dragging other things down by adding to much time to getting something done, that process should be reworked or at least revisited. In these cases process is getting in the way of doing what Big Co. should be doing - which is the work of the company for the customer. Missing that mark overall is tantamount to failure as a whole.
Now - I admit, that I share some of the sentiment that was expressed by Mr. Fury on this one: process = progress seems to be a little off the mark in the situation that he describes. To the point where for a little while when I would see this supposedly inspirational picture hanging around our building I would take a black Dry Erase marker and add the programmers negation to it ("!=") placing an exclamation mark in front of the equals sign. Thus changing the equation from a equals to a "not equals". However as I think about this situation even more, even the not is a little overkill (just moving to the other extreme).
The Bad
Process used as a shield against new work or used as a way to send people into a wait state - or cause them to circle because they have not paid homage to the process is using it in a way that it should never be intended. Those people are using process to attempt to slow things down because they are overloaded, overworked or just plain a pain in the ass. In any case - it certainly does not equal progress, quite the opposite in fact.
In this sense - I agree with Mr. Fury because he pointed out in his case that the process was getting in the way. In fact it was adding additional time and drag to what he was attempting to get done. In a number of ways this is doing process for the sake of doing it and not because it is adding value to the job or the work being done. Sometimes it is tolerable to allow process to add a 'factor' onto work being done, but when the additional work being done really feels like it is busy work, or work gone to waste - that process should be dropped or changed it is no longer achieving whatever the process' original goal was.
I liken this bad state of process to the current state of Unions. When you are 'not permitted' to do something as simple as plugging your laptop into a network port in a building because that is a 'union job', that is process for the sake of process and is just plain stupid.
The Good
Process that helps communicate amongst many and various groups inside of Big Co. This is the equality that I think the picture is attempting to draw out. As a company grows it will have need to attempt to keep a bunch of separate units all on the same page. The increasing size of any company makes this increasingly difficult. In this case a little process can help and be beneficial. The caveat that I make is that the process needs to be defined and agreed to by both sides of a given communication and has to be helpful to them both. This decision to add process then needs to be revisited on a semi-regular basis to verify that the process has not grown stale and the need for it long since gone away. Only here do I think that process = progress - using process to help progress.
Overall - I am not sure the direct equality makes sense even with my definition for "The Good". A little process doesn't hurt where it makes sense - but when the process goes bad or is dragging other things down by adding to much time to getting something done, that process should be reworked or at least revisited. In these cases process is getting in the way of doing what Big Co. should be doing - which is the work of the company for the customer. Missing that mark overall is tantamount to failure as a whole.
Subscribe to:
Posts (Atom)
