After Alistair's Keynote, I went to Rachel Davies & Liz Sedley's "Top ten tips to Agile Coaches".
Top ten tips to Agile Coaches - Rachel Davies & Liz Sedley
The session was mainly based on a summary from what Rachel and Liz learned through their experience and while writing their book. I will just write down the tips with my small notes and let you think about them.
10. Get Introduced
Who are you? What do you do? What is your goal?
Explain your point of view to the team you will (or are) coaching and let them understand you are not there to be their boss.
9. Agile is NOT a religion
Spend time and effort to listen and understand the team and their environment. It might very well happen that agility does not fit their situation. Be sensitive to their context.
8. Show respect
Always trust (deeply in your heart, not just for show) that people did their best since the beginning and try to understand why they got in the situation they are in.
Discover the differences between people and use NAMES ("the BA said that the DB guy couldn't do it" versus "Jenny told me that Josh was having troubles to implement it").
Ask what they think about the issues and was suggestions they have and LISTEN to their answer. Pay attention and try to understand. Work with them over those suggestions.
7. Step back to see the big picture
Don't try to fix people. Try to fix the pressures and obligations those people suffer from so that they can do their job decently.
6. Ask questions to spark ideas
Questions make people explain ideas and understand them. It also makes them create arguments and counter-arguments for their ideas. If you can make their ideas work, it will help the team adopt the movement and carry on.
But be careful: ask questions to other people's ideas, not your own. Do not try to force your ideas through those questions.
5. Take time out to reflect
Don't let pressure force your answers. Your calm attitude will relax the team and make them feel more confident. Ask help to other agile coaches/people if you can't think of a good behavior. You don't have to know it all.
4. Introduce the Elephant
Show off the problem that everyone know exists but is silent about it. But don't put it as a pressure. Give the team a chance to suggest solutions, ideas, root causes, etc.
3. Make changes as an experiment
Go slowly. Try some idea and be ready to remove it if it doesn't work. Don't stick to something that won't work just because you think the team should make it work. Try something else and try it again later, in another context. Give the team chances to suggest those changes and experiment with their ideas.
2. Go with the energy of the team
Solve the problem the team wants to solve. Eventually they will address the problems you consider important.
1. Have courage in your convictions
Don't doubt your capacities, the problem is not easy and you can't let people see you doubt yourself. It will discourage them and make them lose confidence in you. Believe you can make a difference or you really won't.
After the talk, they asked for each table of participants to add their own tips. A few of them were really good but, unfortunately, I couldn't write them down. Those are obviously good ideas and NOT religions either. Any problem can have its context in which any of those tips can fail. But in general, thinking about them can only help you. Do you have any tip you feel should enter that list? Please post it as a comment. I've attached their slides although they don't add so much.
Wednesday, September 23, 2009
Saturday, September 12, 2009
Agile 2009 - Day 2 - 25th August - Alistair's Keynote
Tuesday at Agile 2009 started well. The conference provided a very good breakfast with chocolate croissant (I love those), coffee, tea, fruits, juices and different kinds of breads.
From there, everyone went to the Grand Ballroom to watch Alistair Cockburn's Keynote. I won't need to write a full description of Alistair's talk because InfoQ just published the full video of it. So it will be a bit closer to my impressions.
First thing I need to mention is that once Ahmed Sidky (Agile 2009 Program Chair) introduced Alistair, we had an amazing performance of Wind's Song Flutes playing the one Scottish music used in all movies and Alistair was following silently behind. Very impressive entrance. Alistair then explained why wind's song flutes players always walk when playing: "They are running away from the sound".
Past the fun, came the sadness. Alistair started his talk reciting an adapted version of the funeral oration from Shakespeare's Julius Cesar to Agile Software Development. A very impressive performance. It was the introduction to say not that Agile was dead but that it was melted. He compared Agile to an iceberg in the ocean (software development) and said that before, Agile was something that people noticed because it was outstanding from the rest. Nowadays, the iceberg has melted. It is not gone. But it is now part of the ocean. It is now something that is accepted by most people.
He then moved on to his viewing of software development you might know if you read any of his Crystal books or articles or if you attended any session with him.
He defines Developing Software as
People
Making Ideas Concrete
in an Economic Context
He then showed this image that I particularly like:
He explains that Software Development can be considered a finite, goal-directed and cooperative game while building IT Systems is open-ended. This means that when you are developing software you should work in a team to reach a goal and you are done when you make the software achieve that goal. On the other hand, when you think about the whole system, you want to work cooperatively in an open ended game. Meaning you are always in a dilemma between delivering the software and setting up for the next software (or game).
He says also that this game is consisted of 3 possible moves: Invent, Decide, Communicate. With those moves you have to deliver the software and be slightly prepared for the next game.
He then went on to more traditional arguments he uses for Crystal. Team size and criticality of the project are key to decide what practices you should apply. He also mentioned the quality of communication between people and the fact that most means are much more effective than paper to communicate so people should really think about different forms of documentation.
He also talked a little about the Craft focus that is being given to software development lately. He pointed that thinking of any activity as a craft helps you identify the skills required to perform it and the medium available to achieve the goal. Moved a little to the User Experience entrance in the process of software development and how things changed or should change to be more effective in overall.
It was a very good talk. A bit repetitive for those that already attended any session with Alistair but still very a great talk. I definitively recommend you see the whole video from InfoQ and feel free to post comments to start a discussion on any of those subjects.
Next post will present Rachel Davies and Liz Sedley's "Top ten tips to Agile Coaches".
From there, everyone went to the Grand Ballroom to watch Alistair Cockburn's Keynote. I won't need to write a full description of Alistair's talk because InfoQ just published the full video of it. So it will be a bit closer to my impressions.
First thing I need to mention is that once Ahmed Sidky (Agile 2009 Program Chair) introduced Alistair, we had an amazing performance of Wind's Song Flutes playing the one Scottish music used in all movies and Alistair was following silently behind. Very impressive entrance. Alistair then explained why wind's song flutes players always walk when playing: "They are running away from the sound".
Past the fun, came the sadness. Alistair started his talk reciting an adapted version of the funeral oration from Shakespeare's Julius Cesar to Agile Software Development. A very impressive performance. It was the introduction to say not that Agile was dead but that it was melted. He compared Agile to an iceberg in the ocean (software development) and said that before, Agile was something that people noticed because it was outstanding from the rest. Nowadays, the iceberg has melted. It is not gone. But it is now part of the ocean. It is now something that is accepted by most people.
He then moved on to his viewing of software development you might know if you read any of his Crystal books or articles or if you attended any session with him.
He defines Developing Software as
People
Making Ideas Concrete
in an Economic Context
He then showed this image that I particularly like:
He explains that Software Development can be considered a finite, goal-directed and cooperative game while building IT Systems is open-ended. This means that when you are developing software you should work in a team to reach a goal and you are done when you make the software achieve that goal. On the other hand, when you think about the whole system, you want to work cooperatively in an open ended game. Meaning you are always in a dilemma between delivering the software and setting up for the next software (or game).He says also that this game is consisted of 3 possible moves: Invent, Decide, Communicate. With those moves you have to deliver the software and be slightly prepared for the next game.
He then went on to more traditional arguments he uses for Crystal. Team size and criticality of the project are key to decide what practices you should apply. He also mentioned the quality of communication between people and the fact that most means are much more effective than paper to communicate so people should really think about different forms of documentation.
He also talked a little about the Craft focus that is being given to software development lately. He pointed that thinking of any activity as a craft helps you identify the skills required to perform it and the medium available to achieve the goal. Moved a little to the User Experience entrance in the process of software development and how things changed or should change to be more effective in overall.
It was a very good talk. A bit repetitive for those that already attended any session with Alistair but still very a great talk. I definitively recommend you see the whole video from InfoQ and feel free to post comments to start a discussion on any of those subjects.
Next post will present Rachel Davies and Liz Sedley's "Top ten tips to Agile Coaches".
Thursday, September 10, 2009
Agile 2009 - Day 1 - 24th August - Software Quality
On the second slot of monday afternoon, I attended Jim Highsmith's "Zen and the Art of Software Quality". I missed the first 10 minutes but I don't think it was a big deal.
Zen and the Art of Software Quality - Jim Highsmith
When I arrived, Jim was talking about why we should not use the Standish Group Measures to evaluate software development success. The main reason he points is that the outcomes measured are outdated. They focus on projects that are on plan, on schedule and on features.
Meaning that a project that is delayed of a year but has a satisfied customer is a failed project.
A project that achieves an unexpected goal is a failure.
A project that delivers less feature in less time and stops is a failure.
Those are wrong concepts. Canceling a project soon enough is NOT a failure. It is a great success from an agile perspective. It means the client didn't waste his money for several months (or years) until he discovered he couldn't afford (or do) what he wanted to.
One of Jim's sentence that I liked is:
"Target high and miss
might be better than
target low and hit!"
What good is it to estimate every story as an epic story and manage to do it in 6 iterations while you could break the story in smaller ones and deliver 80% of the value in 1 iteration?
His suggestion from this scenario is that we shouldn't think about the old Cost-Scope-Schedule triangle as our variables in software development. That waterfall iron triangle should be replaced by an Agile Iron Triangle constituted of Value-Quality-Constraint where Constraint would be Cost-Scope-Schedule.
His idea is that those are constraints to software development. Variables related that fit in a greater picture. Our questioning should now be something like "how much value can we deliver given a certain level of quality and our constraints".
Jim explained then that there are "two kinds of Quality". An iextrinsic quality that is related to the quality imbued from value a given software has for a customer and an intrinsic quality. The intrinsic quality is closer to what we consider quality nowadays. It is the way the software is done. It is its bugless property, its simplicity, etc.
Separating those qualities help us understand something we already know. It is useless to produce the perfect software that solves nobody's problem.
Jim then defends what I understand as "fail fast". He argued that there is some point where cost outcomes value and that, at this point, the software development should be stopped. If we can pinpoint this moment, it is the best way to be have a good performance. If a feature is not worth being paid for, it should not be implemented. If no feature is worth being paid for then the development should stop. And it is NO failure if that happens in the middle of the original schedule. Quite the opposite!
Jim finished his talk mentioning the Parking Lot Diagram I reproduced below. The diagram very well known in FDD communities focuses on feature releasables. Meaning that, in opposition to the Gantt shart that focuses on tasks, the Parking Lot shows the features that can be released.
That was it. I've uploaded Jim's hand outs for more details.
What I learned:
Revisiting some ideas that were pretty obvious can help refocus on what really matters. It is good to listen to the same ideas without having a brand (XP, Scrum, FDD, etc.).
Please leave your comments and ideas regarding this talk.
Next post will be about Alistair Cockburn's keynote.
Zen and the Art of Software Quality - Jim Highsmith
When I arrived, Jim was talking about why we should not use the Standish Group Measures to evaluate software development success. The main reason he points is that the outcomes measured are outdated. They focus on projects that are on plan, on schedule and on features.
Meaning that a project that is delayed of a year but has a satisfied customer is a failed project.
A project that achieves an unexpected goal is a failure.
A project that delivers less feature in less time and stops is a failure.
Those are wrong concepts. Canceling a project soon enough is NOT a failure. It is a great success from an agile perspective. It means the client didn't waste his money for several months (or years) until he discovered he couldn't afford (or do) what he wanted to.
One of Jim's sentence that I liked is:
"Target high and miss
might be better than
target low and hit!"
What good is it to estimate every story as an epic story and manage to do it in 6 iterations while you could break the story in smaller ones and deliver 80% of the value in 1 iteration?
His suggestion from this scenario is that we shouldn't think about the old Cost-Scope-Schedule triangle as our variables in software development. That waterfall iron triangle should be replaced by an Agile Iron Triangle constituted of Value-Quality-Constraint where Constraint would be Cost-Scope-Schedule.
His idea is that those are constraints to software development. Variables related that fit in a greater picture. Our questioning should now be something like "how much value can we deliver given a certain level of quality and our constraints".
Jim explained then that there are "two kinds of Quality". An iextrinsic quality that is related to the quality imbued from value a given software has for a customer and an intrinsic quality. The intrinsic quality is closer to what we consider quality nowadays. It is the way the software is done. It is its bugless property, its simplicity, etc.
Separating those qualities help us understand something we already know. It is useless to produce the perfect software that solves nobody's problem.
Jim then defends what I understand as "fail fast". He argued that there is some point where cost outcomes value and that, at this point, the software development should be stopped. If we can pinpoint this moment, it is the best way to be have a good performance. If a feature is not worth being paid for, it should not be implemented. If no feature is worth being paid for then the development should stop. And it is NO failure if that happens in the middle of the original schedule. Quite the opposite!
Jim finished his talk mentioning the Parking Lot Diagram I reproduced below. The diagram very well known in FDD communities focuses on feature releasables. Meaning that, in opposition to the Gantt shart that focuses on tasks, the Parking Lot shows the features that can be released.
That was it. I've uploaded Jim's hand outs for more details.What I learned:
Revisiting some ideas that were pretty obvious can help refocus on what really matters. It is good to listen to the same ideas without having a brand (XP, Scrum, FDD, etc.).
Please leave your comments and ideas regarding this talk.
Next post will be about Alistair Cockburn's keynote.
Agile 2009 - Day 1 - 24th August - Agile Coaches
During Monday morning, I was working as a volunteer at Registration. This wasn't as fun as bag stuffing for sure. No big innovations there. Just talking to people, handing bags and shirts. The only ironical part was to received about 6 new items we had to stuff into the bags DURING the morning.
For the afternoon, I attended two talks. The one I will be writing about in this post and Jim Highsmith's one about software quality that will be the focus of my next post.
"What Do Agile Coaches Do?" by Liz Sedley and Rachel Davies
Liz and Rachel started explaining that the session was based on the work they had done to their new book "Agile Coaching". They also pointed out the session was a workshop and that it was aimed to Carlos - internal coach (see the conference personas webpage to a better understanding).
Their first point was that coaching a software development team was not exactly like coaching a soccer team although the name is the same. It led them towards J. Richard Hackman's work. According to Liz and Rachel, Hackman's book named "Leading Teams - Setting the stage for great performances" out stands from other leadership books because it focuses in teams rather than individuals.
From this, they pointed out a couple things that are NOT coaching namely doing someone else's job and directing the team. In opposite, they explained that a coach should provide feedback, explain dynamics, provide suggestions and become useless (they called it: being transitional).
They explained Hackman divides possible coaching interventions in three groups:
On an Educational intervention, the coach would run an activity that could allow the team to a better understanding of what is happening and why. Retrospectives usually fit very well in Educational interventions because they make the team think about their situation and look for improvements therefore increasing their learning.
A Consultative intervention is one that the coach will apply to adjust the situation to a better one. This is the easiest intervention to make since it only requires that the coach have a suggestion of improvement and use its experience to solve the issue. The problem with it is that it does not helps the team become independent since the knowledge about why applying that solution stays with the coach. On the other hand, this is a very good solution when dealing with a team of novice people (or Shu people - see the Dreyfus learning model or the Shu-Ha-Ri model - I will post about both since there were talks about both) because it will show them one technique.
This introduction led us to the workshop itself. The room was split into groups of 3 or 4 people and Rachel and Liz handed over several Scenarios of problems in a team for each group so that the group would suggestion some coaching interventions to each scenario. The activity itself was quite interesting but, as most attendees in the session, I felt just having the division of interventions in 3 kinds was worth the session.
Most of the groups reached a fourth division that could be called "Introspection" that consists in any activity that might help understand the problem. Introspection interventions usually lead to Educational interventions from the own team opposed to Educational interventions from the coach (which might have run the Introspection intervention unknowing what the appropriate intervention was). One can argue that Introspection interventions are always performed before any other and therefore can be considered part of each intervention but the point here is that an introspection intervention may result in different sorts of intervention even if the problem is the same.
More information can be found in Liz and Rachel's slides.
I learned that classifying your actions according to Hackman's suggestion is very useful to self-analysis and to moderate the kind of actions you take. It can also help sharing experience between coaches and can probably be used in some behavioral studies related to cultural differences.
The next post will regard Jim Highsmith's "Zen and the Art of Software Quality" presentation. Please leave your comments here and there.
For the afternoon, I attended two talks. The one I will be writing about in this post and Jim Highsmith's one about software quality that will be the focus of my next post.
"What Do Agile Coaches Do?" by Liz Sedley and Rachel Davies
Liz and Rachel started explaining that the session was based on the work they had done to their new book "Agile Coaching". They also pointed out the session was a workshop and that it was aimed to Carlos - internal coach (see the conference personas webpage to a better understanding).
Their first point was that coaching a software development team was not exactly like coaching a soccer team although the name is the same. It led them towards J. Richard Hackman's work. According to Liz and Rachel, Hackman's book named "Leading Teams - Setting the stage for great performances" out stands from other leadership books because it focuses in teams rather than individuals.
From this, they pointed out a couple things that are NOT coaching namely doing someone else's job and directing the team. In opposite, they explained that a coach should provide feedback, explain dynamics, provide suggestions and become useless (they called it: being transitional).
They explained Hackman divides possible coaching interventions in three groups:
- Motivational intervention: one that tries to increase the effort of the team
- Consultative intervention: one that attempts to improve the quality of the process
- Educational intervention: one that aims to improve learning
On an Educational intervention, the coach would run an activity that could allow the team to a better understanding of what is happening and why. Retrospectives usually fit very well in Educational interventions because they make the team think about their situation and look for improvements therefore increasing their learning.
A Consultative intervention is one that the coach will apply to adjust the situation to a better one. This is the easiest intervention to make since it only requires that the coach have a suggestion of improvement and use its experience to solve the issue. The problem with it is that it does not helps the team become independent since the knowledge about why applying that solution stays with the coach. On the other hand, this is a very good solution when dealing with a team of novice people (or Shu people - see the Dreyfus learning model or the Shu-Ha-Ri model - I will post about both since there were talks about both) because it will show them one technique.
This introduction led us to the workshop itself. The room was split into groups of 3 or 4 people and Rachel and Liz handed over several Scenarios of problems in a team for each group so that the group would suggestion some coaching interventions to each scenario. The activity itself was quite interesting but, as most attendees in the session, I felt just having the division of interventions in 3 kinds was worth the session.
Most of the groups reached a fourth division that could be called "Introspection" that consists in any activity that might help understand the problem. Introspection interventions usually lead to Educational interventions from the own team opposed to Educational interventions from the coach (which might have run the Introspection intervention unknowing what the appropriate intervention was). One can argue that Introspection interventions are always performed before any other and therefore can be considered part of each intervention but the point here is that an introspection intervention may result in different sorts of intervention even if the problem is the same.
More information can be found in Liz and Rachel's slides.
I learned that classifying your actions according to Hackman's suggestion is very useful to self-analysis and to moderate the kind of actions you take. It can also help sharing experience between coaches and can probably be used in some behavioral studies related to cultural differences.
The next post will regard Jim Highsmith's "Zen and the Art of Software Quality" presentation. Please leave your comments here and there.
Thursday, September 3, 2009
Agile 2009 - Day 0 - 23th August - Bag Stuffing
As a volunteer at Agile 2009, you get to attend the conference without having to pay the conference fee (which is NOT cheap) in exchange for some (~20h) of your working time. Most of this time is spend by helping out during sessions or just in crowd control during the big events.
However, there is also some back stage work to be done BEFORE the conference really starts. That is Bag Stuffing.
Bag Stuffing is an activity that consists in generating enough conference bags with all sponsor materials within each bag. This year the volunteers received a lot of help from various people and we had the honor of having some Kanban people to help us improve our process as we went on.
Our first job was to gather boxes together and discover what should go into each bag. It wasn't the easiest job on Earth since nobody knew the content of the boxes nor if we were missing something or not. It ended up that we had 3 teams. One building up a sample bag with every item they got and counting and checking that every sponsor had their items listed. One building up a redundant bag that would verify that the first team got everything and that we could point each items' boxes. A last team that placed the boxes in a line with a sample item on the top of them so that we could easily identify the piles.
This job got done pretty quickly and very soon we had a list of available items and discovered some items were missing and got the news of a few new items arriving. Having included those new items and accounted for the missing ones, the group got split into two groups that would assemble the bags.
The process started with 7 people on each group following different ideas:
As expected, the team 1 was faster on the first iterations but soon team 2 managed to be more productive. Both team identified a problem with the table's height. However, for security reasons, none was allowed to make the tables higher which resulted in some fatigue to everyone. After the first hour, we had discovered the bottleneck for both teams and, surprise, it wasn't within the teams bounds. The greatest issue was to get the cars full of bags to the upper level and unload them into the registration area. So some people got assigned to that task and some adjustments were made.
Team 1 could easily fit the reduction of people by just assigning more items to each person down the line (we already had extra persons in the line). It even managed to have a person (me) dedicated to refilling supplies (lots of times for both teams).
Team 2 suffered the loss a bit more since each person less in the team meant a reasonable amount of bags that could flow. But they came out with an improvement to reduce their path. Instead of laying out the tables in a line, they moved them to be a U shape. This way, their path got considerably shorter.
It turned out that this was became a problem because the bottleneck would still be getting the bags upstairs but, this time, because the elevators were not as responsive as possible. So Team 1 adapted to this. People would take a small break every time a car got filled up and so they could rest from fatigue.
Team 2 also enjoyed it because they were moving around so much (having to go back all the table to restart filling a bag) that they were getting pretty tired.
By the end of the morning, both teams had completed around 800 bags and most people left for lunch. I wasn't at the afternoon's work but heard some good improvements from them. The team that picked up line 1 mainly followed what was already being done since it was reasonably simple and effective.
On the other hand, team 2 identified some very nice improvements. They laid out the tables in the shape of a star (like to image on the right). This way, they managed to dramatically reduce the length of their path to fill a bag, have a quick an big stock of materials and improve their speed. It is also fair to say that it was only possible because they had only 4 people working (they were missing some volunteers).
In any way, the results were amazing. About 1400 bags were filled and unloaded from 8am to 3pm by some 20 people in the morning shift and about 12 in the noon shift. Great work from everyone and good lessons from applying Kanban techniques.
However, there is also some back stage work to be done BEFORE the conference really starts. That is Bag Stuffing.
Bag Stuffing is an activity that consists in generating enough conference bags with all sponsor materials within each bag. This year the volunteers received a lot of help from various people and we had the honor of having some Kanban people to help us improve our process as we went on.
Our first job was to gather boxes together and discover what should go into each bag. It wasn't the easiest job on Earth since nobody knew the content of the boxes nor if we were missing something or not. It ended up that we had 3 teams. One building up a sample bag with every item they got and counting and checking that every sponsor had their items listed. One building up a redundant bag that would verify that the first team got everything and that we could point each items' boxes. A last team that placed the boxes in a line with a sample item on the top of them so that we could easily identify the piles.
This job got done pretty quickly and very soon we had a list of available items and discovered some items were missing and got the news of a few new items arriving. Having included those new items and accounted for the missing ones, the group got split into two groups that would assemble the bags.
The process started with 7 people on each group following different ideas:
- A production line where the bags would flow from one side to the other being moved by the people assigned to stuff in certain items.
- A pick-up line where the people would flow from one side of table to the other filling a complete bag each item at a time.
As expected, the team 1 was faster on the first iterations but soon team 2 managed to be more productive. Both team identified a problem with the table's height. However, for security reasons, none was allowed to make the tables higher which resulted in some fatigue to everyone. After the first hour, we had discovered the bottleneck for both teams and, surprise, it wasn't within the teams bounds. The greatest issue was to get the cars full of bags to the upper level and unload them into the registration area. So some people got assigned to that task and some adjustments were made.
Team 1 could easily fit the reduction of people by just assigning more items to each person down the line (we already had extra persons in the line). It even managed to have a person (me) dedicated to refilling supplies (lots of times for both teams).
Team 2 suffered the loss a bit more since each person less in the team meant a reasonable amount of bags that could flow. But they came out with an improvement to reduce their path. Instead of laying out the tables in a line, they moved them to be a U shape. This way, their path got considerably shorter.
It turned out that this was became a problem because the bottleneck would still be getting the bags upstairs but, this time, because the elevators were not as responsive as possible. So Team 1 adapted to this. People would take a small break every time a car got filled up and so they could rest from fatigue.
Team 2 also enjoyed it because they were moving around so much (having to go back all the table to restart filling a bag) that they were getting pretty tired.
By the end of the morning, both teams had completed around 800 bags and most people left for lunch. I wasn't at the afternoon's work but heard some good improvements from them. The team that picked up line 1 mainly followed what was already being done since it was reasonably simple and effective.
On the other hand, team 2 identified some very nice improvements. They laid out the tables in the shape of a star (like to image on the right). This way, they managed to dramatically reduce the length of their path to fill a bag, have a quick an big stock of materials and improve their speed. It is also fair to say that it was only possible because they had only 4 people working (they were missing some volunteers).In any way, the results were amazing. About 1400 bags were filled and unloaded from 8am to 3pm by some 20 people in the morning shift and about 12 in the noon shift. Great work from everyone and good lessons from applying Kanban techniques.
Saturday, July 18, 2009
Forget Art! Refactoring viewed as a critic
It has been some time since the last post about the whole "Programming is maths but communicating is art". Since then I've had some very interesting discussions with an architecture critic. She obviously got terrified when I told her I used Wikipedia's Art definition to think about programming and refactoring.
It led us to a deeper search of what art is or can be considered. One of the key points Sophia was defending was that we shouldn't give that much value to Art. First because Art, most of times, is not supposed be something nice or pretty. It is supposed to shock, change your view of the world and make you rethink your bases.
I'm not going deeper into the discussion "what Art is" because I don't have enough knowledge to argue in it anyway. I'll take Sophia's definition because it will led us to some interesting discussions.
So, if Art should change your way of thinking the world, we probably shouldn't want our code to be Art. Pretty much the opposite in fact! Uncle Bob quotes Ward Cunningham: "Clean code is a code that is pretty much what you expected it to be". Well, how can something that is pretty much what you expected make you revalue your life and the world around you? It shouldn't! So any clean code should be the complete opposite of Art and the previous post got it all wrong.
So a clean code itself is not Art and the programmers that write it are not artists. However, there is a big deal of work involved into transforming a code that a computer can understand into a code that a human being can understand.
Sophia suggested us that analyzing someone's work (including our own) is a critic's work. You observe and analyze the whats, whys and hows someone ended up creating the object of your analysis. You read it, rethinking it, twist it and try to extract every piece of information you can from that thing.
Once you believe you have enough knowledge about what you were studying, you write to describe the questions you found about the work. If you manage to achieve a good result, you will provide a very different overview and understanding of the work. You will give it a new meaning that will lead people to understand that work and others from your view point.
That was way too abstract so going back to our practical world. Refactoring code is like criticizing it. You understand it and rewrite it offering your own understanding of why that code needs to be the way it is. By refactoring we are not (or should not) change the result of the previous work. In this sense, we cannot really think of it as a creation process. We are obviously producing something just like a critic produces something. But what really matters is the binaries themselves. The fact that the computer can follow those instructions and do what it is supposed to do. We only provide a view point about what, why and how those binaries are the way they are.
Accepting this explanation can help us understand a few of the problems we face. First, considering refactoring as a criticism of the code makes it very easy to understand why there is no way to let the code "perfect". It also justifies why programmers should read loads of codes. To be a good critic you have to understand what other critics are saying or said.
Another thing that actually fits very well in this description is that refactoring requires the author to have a good capacity to write. You can have an amazing understanding of a work and still be the crappiest critic if nobody can understand what you are saying.
At last, it also fits very well Uncle Bob's idea of school of thoughts regarding code. Critics tend to analyze a work according to the knowledge and understanding they have learned from other works or other critics. Those characterize school of thoughts and fit very well the way we feel about coding styles. Java people tend to hate the return result unless condition style while rubyist find it very natural.
I doubt this is the last post about that subject and I hope to get more replies about your opinions and ideas. This is meant to be provide an answer but more likely to point some questions. Would you consider yourself a critic? What are the flaws in that viewpoint? Do you have another parallel to make?
It led us to a deeper search of what art is or can be considered. One of the key points Sophia was defending was that we shouldn't give that much value to Art. First because Art, most of times, is not supposed be something nice or pretty. It is supposed to shock, change your view of the world and make you rethink your bases.
I'm not going deeper into the discussion "what Art is" because I don't have enough knowledge to argue in it anyway. I'll take Sophia's definition because it will led us to some interesting discussions.
So, if Art should change your way of thinking the world, we probably shouldn't want our code to be Art. Pretty much the opposite in fact! Uncle Bob quotes Ward Cunningham: "Clean code is a code that is pretty much what you expected it to be". Well, how can something that is pretty much what you expected make you revalue your life and the world around you? It shouldn't! So any clean code should be the complete opposite of Art and the previous post got it all wrong.
So a clean code itself is not Art and the programmers that write it are not artists. However, there is a big deal of work involved into transforming a code that a computer can understand into a code that a human being can understand.
Sophia suggested us that analyzing someone's work (including our own) is a critic's work. You observe and analyze the whats, whys and hows someone ended up creating the object of your analysis. You read it, rethinking it, twist it and try to extract every piece of information you can from that thing.
Once you believe you have enough knowledge about what you were studying, you write to describe the questions you found about the work. If you manage to achieve a good result, you will provide a very different overview and understanding of the work. You will give it a new meaning that will lead people to understand that work and others from your view point.
That was way too abstract so going back to our practical world. Refactoring code is like criticizing it. You understand it and rewrite it offering your own understanding of why that code needs to be the way it is. By refactoring we are not (or should not) change the result of the previous work. In this sense, we cannot really think of it as a creation process. We are obviously producing something just like a critic produces something. But what really matters is the binaries themselves. The fact that the computer can follow those instructions and do what it is supposed to do. We only provide a view point about what, why and how those binaries are the way they are.
Accepting this explanation can help us understand a few of the problems we face. First, considering refactoring as a criticism of the code makes it very easy to understand why there is no way to let the code "perfect". It also justifies why programmers should read loads of codes. To be a good critic you have to understand what other critics are saying or said.
Another thing that actually fits very well in this description is that refactoring requires the author to have a good capacity to write. You can have an amazing understanding of a work and still be the crappiest critic if nobody can understand what you are saying.
At last, it also fits very well Uncle Bob's idea of school of thoughts regarding code. Critics tend to analyze a work according to the knowledge and understanding they have learned from other works or other critics. Those characterize school of thoughts and fit very well the way we feel about coding styles. Java people tend to hate the return result unless condition style while rubyist find it very natural.
I doubt this is the last post about that subject and I hope to get more replies about your opinions and ideas. This is meant to be provide an answer but more likely to point some questions. Would you consider yourself a critic? What are the flaws in that viewpoint? Do you have another parallel to make?
Tuesday, May 12, 2009
Programming is maths! But communicating is art...
I tried to sum up the contents of this post (which will surely be long) in the title.
The discussion came up yesterday after the master's thesis presentation of a friend of mine (Daniel Cukier). His proposal was way too unconventional to pass easily. During the teachers' comments on his thesis, Prof. Valdemar Setzer pointed out that he disagrees on Daniel's sentence that said (from my memory that is brief and unprecise) "The art of programming ...".
Prof. Setzer says he disagrees with Knuth (and Daniel) on the fact that programming is an art.
The whole deal led us (me and Mariana Bravo) to a discussion about what part of what we do is art. Because, obviously, both of us believe that some part of it IS art. We couldn't disagree with Prof. Setzer. Indeed, talking to a machine is pretty much the opposite of art. Formalism, logic and maths are key elements to be used very consciously to achieve the goal of writing something that compiles and run as expected in a computer. From this I conclude that writing to execute is not art.
I also claim that this is also the part of computer science that is very well mastered! Programmers are great to write something that execute and does what was wanted.
You can see the proof to this claim on every programming competition out there. ACM-ICPC, Yahoo HackDay, Google Code Jam, Imagine Cup and many others. Those competitions stress this aspect of computer science. They expect the people involved to write a software that executes and does what was expected. And people do GREAT! I have seen amazing codes, amazing solutions and wonderful applications being built on those contests. Yet, every company involved in those contests (to hire the winners) still fights to write better software and are present in tons of conferences trying to achieve better results. The winners of those contests are usually amazing programmers in the sense that they are great to find solutions to a problem and have it compile and run. Why are we still struggling to write better software then?
The answer is not mine. It has been around for ages and loads of people probably already said it before me (and probably much better than me): "Because the greatest problem of software is the maintenance".
During the maintenance, it is no longer THAT important to talk to the machine. The code is already talking to the machine somehow and some part of it should be saying something different. The code now enters a whole new realm. The realm of talking to people.
Having your code talk to people is very similar to having a letter or an email or even a blog communicating your ideas. One could argue that writing with code is bounded to a formalism that breaks the communication and beauty that can be achieved. To which I reply that, for many years, poetry bounded itself to very rigid forms such as Alexandrine, Iambic Pentameters, Dodecasyllabes and others. I believe I can say that nobody would dare deny that there is great art done following those rigid rules.
Uncle Bob says in his Clean Code book: "A good and clean code should read as a newspaper article". He says so because he believes this is the only way one can be quickly parse a code and focus only on what is important to the current matter. It means that complexity should be hidden as much as possible to avoid having to bump into her all the time. It also means (indirectly) that there are TONS of ways to write the same code, that is, to achieve the same computer execution result.
Raymond Queneau is a famous french writer author of "Exercices de styles" (Style exercises) and many others. His book presents 99 versions of the same story written in the same language (French) with different styles. Each of the versions have different writing styles and present the reader with a new experience of the same facts. Writing the book was surely an amazing exercise but reading it is also very interesting. Reading 99 ways to achieve the same result makes you think a lot about what you actually write.
As programmers, we are subjected to such exercise very often. There are dozens of frameworks to achieve the same goal (many times in the same language), there are dozens of libraries that do the same thing but the code is ALWAYS VERY different.
I propose (and will try to) that, as programmers, we force ourselves to take part of this exercise. Our version control systems help to do so and we should be doing it all the time. Write a first version of your code, save it (commit), write a new version of your code (maybe from the first one or not), save it and repeat the action.
Such description of the thing makes me (and you, probably) remind that we already to this over and over and over. Refactoring is exactly the process to rewrite to achieve the same goal but changing the style.
Martin Fowler's definition of Refactoring is "a change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior". It is not really the same thing I previously stated right? This is where the art comes along.
Here is Fowler's trick: "... to make it easier to understand and cheaper to modify...". This definition is amazingly vague! How the heck do you make something get easier to understand or cheaper to modify? Formally you don't! You can only find out what makes the code easier subjectively. You can only know what makes it cheaper to modify when you actually have to modify it and do it.
Uncle Bob uses the same trick. He says Clean Code helps you write better code and detect bad code. Again, this is highly subjective! And more: it depends heavily on the programmer's ability to communicate through the code with other people. Such ability is heavily related to art!
According to Wikipedia (and please feed me better info if you have them),
"Art is the process or product of deliberately arranging elements in a way that appeals to the senses or emotions".
Again from Wikipedia, "Communication can be perceived as a two-way process in which there is an exchange and progression of thoughts, feelings or ideas towards a mutually accepted goal or direction".
From those definitions, I would say Art is a form of Communication. Moreover Poetry, Literature, Theater, Painting, Sculpting, Music, Dance and other art activities are holders to a communication channel between the artist and the watcher.
Poetry and Literature use words.
Theater and Dance use the human body.
Painting and Sculpting rely on colors and textures while Music bases itself on sounds.
The study of art is therefore heavily related to the study of how to communicate with people from various backgrounds and ideas. This is the art matter that is missing in the computer science courses (at least the one I followed) and the computer related careers.
Regarding literature, someone can put a word after another and make it "run", that is, make sense. But it takes a lot more effort to pass from that to art.
Programming follows the same rule.
Loads of programmers can put an instruction after another but it takes an amazing work to transform that into something that will communicate later on.
My conclusion from this post (more an article than a post) is that computer science courses are very important because they teach you to communicate with the computer. But once you learned (and it takes more time than just the course) to make the computer do what you want, you must learn to communicate with people. Actually, you should probably do both at the same time but the important part is that you always remember that "executing" is poor and communicating can be art.
Now all that I need is to actually incorporate such thinking and begin acting to improve in this sense.
The discussion came up yesterday after the master's thesis presentation of a friend of mine (Daniel Cukier). His proposal was way too unconventional to pass easily. During the teachers' comments on his thesis, Prof. Valdemar Setzer pointed out that he disagrees on Daniel's sentence that said (from my memory that is brief and unprecise) "The art of programming ...".
Prof. Setzer says he disagrees with Knuth (and Daniel) on the fact that programming is an art.
"Programming is formalizing your ideas in order to make a computer execute them and, therefore, cannot be considered art since it must not be done or influenced by your subconscious and must be an activity on which you are always conscious of your actions."This is yet another imprecise and crappy translation of what happened but it does not matter. The idea is mainly that if we need to be fully conscious of all our actions when programming, then this activity cannot be considered art since art relies heavily on one's subconscious.
The whole deal led us (me and Mariana Bravo) to a discussion about what part of what we do is art. Because, obviously, both of us believe that some part of it IS art. We couldn't disagree with Prof. Setzer. Indeed, talking to a machine is pretty much the opposite of art. Formalism, logic and maths are key elements to be used very consciously to achieve the goal of writing something that compiles and run as expected in a computer. From this I conclude that writing to execute is not art.
I also claim that this is also the part of computer science that is very well mastered! Programmers are great to write something that execute and does what was wanted.
You can see the proof to this claim on every programming competition out there. ACM-ICPC, Yahoo HackDay, Google Code Jam, Imagine Cup and many others. Those competitions stress this aspect of computer science. They expect the people involved to write a software that executes and does what was expected. And people do GREAT! I have seen amazing codes, amazing solutions and wonderful applications being built on those contests. Yet, every company involved in those contests (to hire the winners) still fights to write better software and are present in tons of conferences trying to achieve better results. The winners of those contests are usually amazing programmers in the sense that they are great to find solutions to a problem and have it compile and run. Why are we still struggling to write better software then?
The answer is not mine. It has been around for ages and loads of people probably already said it before me (and probably much better than me): "Because the greatest problem of software is the maintenance".
During the maintenance, it is no longer THAT important to talk to the machine. The code is already talking to the machine somehow and some part of it should be saying something different. The code now enters a whole new realm. The realm of talking to people.
Having your code talk to people is very similar to having a letter or an email or even a blog communicating your ideas. One could argue that writing with code is bounded to a formalism that breaks the communication and beauty that can be achieved. To which I reply that, for many years, poetry bounded itself to very rigid forms such as Alexandrine, Iambic Pentameters, Dodecasyllabes and others. I believe I can say that nobody would dare deny that there is great art done following those rigid rules.
Uncle Bob says in his Clean Code book: "A good and clean code should read as a newspaper article". He says so because he believes this is the only way one can be quickly parse a code and focus only on what is important to the current matter. It means that complexity should be hidden as much as possible to avoid having to bump into her all the time. It also means (indirectly) that there are TONS of ways to write the same code, that is, to achieve the same computer execution result.
Raymond Queneau is a famous french writer author of "Exercices de styles" (Style exercises) and many others. His book presents 99 versions of the same story written in the same language (French) with different styles. Each of the versions have different writing styles and present the reader with a new experience of the same facts. Writing the book was surely an amazing exercise but reading it is also very interesting. Reading 99 ways to achieve the same result makes you think a lot about what you actually write.
As programmers, we are subjected to such exercise very often. There are dozens of frameworks to achieve the same goal (many times in the same language), there are dozens of libraries that do the same thing but the code is ALWAYS VERY different.
I propose (and will try to) that, as programmers, we force ourselves to take part of this exercise. Our version control systems help to do so and we should be doing it all the time. Write a first version of your code, save it (commit), write a new version of your code (maybe from the first one or not), save it and repeat the action.
Such description of the thing makes me (and you, probably) remind that we already to this over and over and over. Refactoring is exactly the process to rewrite to achieve the same goal but changing the style.
Martin Fowler's definition of Refactoring is "a change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior". It is not really the same thing I previously stated right? This is where the art comes along.
Here is Fowler's trick: "... to make it easier to understand and cheaper to modify...". This definition is amazingly vague! How the heck do you make something get easier to understand or cheaper to modify? Formally you don't! You can only find out what makes the code easier subjectively. You can only know what makes it cheaper to modify when you actually have to modify it and do it.
Uncle Bob uses the same trick. He says Clean Code helps you write better code and detect bad code. Again, this is highly subjective! And more: it depends heavily on the programmer's ability to communicate through the code with other people. Such ability is heavily related to art!
According to Wikipedia (and please feed me better info if you have them),
"Art is the process or product of deliberately arranging elements in a way that appeals to the senses or emotions".
Again from Wikipedia, "Communication can be perceived as a two-way process in which there is an exchange and progression of thoughts, feelings or ideas towards a mutually accepted goal or direction".
From those definitions, I would say Art is a form of Communication. Moreover Poetry, Literature, Theater, Painting, Sculpting, Music, Dance and other art activities are holders to a communication channel between the artist and the watcher.
Poetry and Literature use words.
Theater and Dance use the human body.
Painting and Sculpting rely on colors and textures while Music bases itself on sounds.
The study of art is therefore heavily related to the study of how to communicate with people from various backgrounds and ideas. This is the art matter that is missing in the computer science courses (at least the one I followed) and the computer related careers.
Regarding literature, someone can put a word after another and make it "run", that is, make sense. But it takes a lot more effort to pass from that to art.
Programming follows the same rule.
Loads of programmers can put an instruction after another but it takes an amazing work to transform that into something that will communicate later on.
My conclusion from this post (more an article than a post) is that computer science courses are very important because they teach you to communicate with the computer. But once you learned (and it takes more time than just the course) to make the computer do what you want, you must learn to communicate with people. Actually, you should probably do both at the same time but the important part is that you always remember that "executing" is poor and communicating can be art.
Now all that I need is to actually incorporate such thinking and begin acting to improve in this sense.
Subscribe to:
Posts (Atom)
Posts
