I had a conversation with a friend last night and he was telling me about how an acquaintance of his, a project manager, had to watch the development team like a hawk to ensure that they delivered on time. If you work on technology projects you have likely seen this behavior before, and in my mind this is a dangerous game.
To understand why we need to go back in time to when we were kids. As a child my bedroom was always a mess and I'm sure that I'm not alone on that. And every couple of months my Mom would tell me, "you aren't leaving your room until it is clean". If you had a messy room too you can probably guess what I did. Sure, I might have put a few of my toys on the shelf where they belonged, but at least half of the junk on my floor would end up getting shoved under the bed or in the closet. About half an hour later I would proclaim, "my room is clean!" But was it really? Of course the first thing my mother did was look under the bed and in the closet.
Now I have a question for you. When you are snapping at your team to pick up the pace to meet a deadline, are you looking under the bed and in the closet? Many software project managers aren't programmers themselves, so they have no way of knowing if the product is good, or even what "good" means. All the PM knows is if it is "done" or it isn't.
As a PM you you should ease up the reigns and realize that you are an equal member of the team, and not the "boss". You have a role like everyone else, and it isn't your place to crack the whip. It is a "team" effort. Instead it is your job to work with your partners and solicit honest feedback about the quality and maintainability of the product being delivered, and the team isn't going to be honest with you if you act like the "boss".
If you have been a project manager for some time you should look back at all of those software projects you worked on perform a mental recap. For each of those projects you should ask yourself the following questions. Are the users of that product happy about using it, or does everyone grumble when they hear it's name? Are the people maintaining the product happy with it, or are they constantly trying to fix it? Was the project a true success and did it end up meeting the needs that it was designed for?
Software quality is at least as important as meeting deadlines so make sure that you account for it.
Thursday, April 10, 2014
Saturday, April 17, 2010
Use the right tool for the job, or not
An intelligent developer always advocates that you should "use the right tool for the job". But is there really a "right" tool, or is that just the developer's way of being tolerant to other languages and tools? I suggest that in 90% of development projects the "right" tool is strictly the preference of the developer and that there is no concrete reason that the tool chosen is the best fit for the particular job.
My thinking on this is the result of moderating the Battle of the Frameworks panel at Philly ETE last week. The audio for the session is available, so you can listen to it yourself and see if it matches what I feel happened.
The first question asked of the panel was, if a friend of yours someone came up to you and said they were starting a web-based business, what programming language and framework would you recommend to them, and why? The answer that several of the panelists gave was that you should use the right tool for the job. At the time this made sense to me, and I didn't disagree, but I have a somewhat different opinion now. The reason for my change in thinking is that the "best tool" for general web development was different for different people. This wasn't the result of a specific question, but more of a feeling.
I had been talking a lot with Dan Allen (author Seam in Action) and Lincoln Baxter III (creator of PrettyFaces) at the conference, and they really felt that Java 6 EE was really a great platform for web development, implying that it was the right tool for the job. Their reasoning seems to be that if you use Java, Java 6 EE is a great tool to use because it is the official platform for Java that was created from a standards process. In addition, because it is based on standards, and not a proprietary implementation, there are several implementations to choose. So vendor lock-in seems to be part of their reasoning.
Also at the conference I sat in on the Groovy meet-up, and it was there that Venkat Subramaniam (author of Programming Groovy) said that for web development you would want to use a dynamic language. So to Venkat, the right tool is Groovy or some other dynamic language because somehow a static language like Java makes web development harder. This was mirrored by Obie Fernandez (author of the Rails Way) at the same panel in 2008 that said, "There's basically no reason whatsoever that anyone in their right mind would do anything web related in Java". For the record, following the panel in 2008 he said they some of the stuff he said was just to start fires, so although he may have exaggerated a little to stir the pot, I still think he generally believes this statement.
So how do we reconcile these differences? Every member of the panel is an experienced developer, most of them authors, working for some of the biggest names in our industry, and their opinions are well respected. So why do they say "use the best tool for the job", yet seem to have differences in how they determine what that tool is? the majority of the panelists, if not all, have worked with both static and dynamic languages. So they know what the differences are, yet it doesn't seem like they would agree on the same tools given a specific set of requirements.
Perhaps there is no right tool. Perhaps the right tool is whatever tool you feel comfortable using. Perhaps Java, Ruby, and Groovy are all different brands of shovels, and you just need to pick which color you like since they all do the same things. And Subversion and Git are merely rakes, one green and one blue. Same for Maven and Ant.
So perhaps the real answer to the question of what is the right tool is simply, "the tool that you like to use".
My thinking on this is the result of moderating the Battle of the Frameworks panel at Philly ETE last week. The audio for the session is available, so you can listen to it yourself and see if it matches what I feel happened.
The first question asked of the panel was, if a friend of yours someone came up to you and said they were starting a web-based business, what programming language and framework would you recommend to them, and why? The answer that several of the panelists gave was that you should use the right tool for the job. At the time this made sense to me, and I didn't disagree, but I have a somewhat different opinion now. The reason for my change in thinking is that the "best tool" for general web development was different for different people. This wasn't the result of a specific question, but more of a feeling.
I had been talking a lot with Dan Allen (author Seam in Action) and Lincoln Baxter III (creator of PrettyFaces) at the conference, and they really felt that Java 6 EE was really a great platform for web development, implying that it was the right tool for the job. Their reasoning seems to be that if you use Java, Java 6 EE is a great tool to use because it is the official platform for Java that was created from a standards process. In addition, because it is based on standards, and not a proprietary implementation, there are several implementations to choose. So vendor lock-in seems to be part of their reasoning.
Also at the conference I sat in on the Groovy meet-up, and it was there that Venkat Subramaniam (author of Programming Groovy) said that for web development you would want to use a dynamic language. So to Venkat, the right tool is Groovy or some other dynamic language because somehow a static language like Java makes web development harder. This was mirrored by Obie Fernandez (author of the Rails Way) at the same panel in 2008 that said, "There's basically no reason whatsoever that anyone in their right mind would do anything web related in Java". For the record, following the panel in 2008 he said they some of the stuff he said was just to start fires, so although he may have exaggerated a little to stir the pot, I still think he generally believes this statement.
So how do we reconcile these differences? Every member of the panel is an experienced developer, most of them authors, working for some of the biggest names in our industry, and their opinions are well respected. So why do they say "use the best tool for the job", yet seem to have differences in how they determine what that tool is? the majority of the panelists, if not all, have worked with both static and dynamic languages. So they know what the differences are, yet it doesn't seem like they would agree on the same tools given a specific set of requirements.
Perhaps there is no right tool. Perhaps the right tool is whatever tool you feel comfortable using. Perhaps Java, Ruby, and Groovy are all different brands of shovels, and you just need to pick which color you like since they all do the same things. And Subversion and Git are merely rakes, one green and one blue. Same for Maven and Ant.
So perhaps the real answer to the question of what is the right tool is simply, "the tool that you like to use".
Wednesday, April 14, 2010
Philly ETE 2010 - Battle of the Frameworks (slides)
Here are the slides from the Battle of the Frameworks, which was held on April 9th 2010.
The audio of the event can be found here.
The audio of the event can be found here.
Saturday, January 30, 2010
The Humane Interface
It has been a long time since my last post, but it is time to shake the dust off my blog and get back to work. There are a few cool things going on for me including a new book, a speaking gig, and some interesting projects. I'll post about all that stuff in the weeks to come, but for now I wanted to share a book that I am reading, The Humane Interface by Jef Raskin.
Wait, wait! Don't go!
I expect that many of my readers are coders and it might not seem like this posting is for coders, but it is especially for coders. I have been hacking and crafting code for fun and profit for over 20 years now. I have read all of the classic programming bibles, from the Mythical Man Month, to Design Patterns by the Gang of Four. All of them have been about writing the code, or managing the project. But all of these ignore, and rightfully so given their topics, that the success of a project depends on the user liking the product. And the user of course can't see the beautiful domain model, clean code, and vast array of automated tests that you have created. All they see is the interface.
As a coder I had no idea that interface design was a science, and instead always thought that it was an art. But it is a science, and it has nothing to do with nice looking graphics. This book taught me that.
As I read through the book, which I am still in the progress of reading, I have been posting quotes from the book on Google Wave that encapsulate the important bits for me that I know that I need to remember. If you want to read them or post your own you can find the Wave my searching for with:public by:iamroberthanson "Humane Interface". In the rest of this entry I want to share a few choice quotes from the book along with some explanation so that you can see why this book would be a valuable edition to your bookshelf.
This might seem obvious, but if it was so obvious it wouldn't be ignored so often. Raskin discussed this in some length, including why it is important to include undo/redo functionality, the importance of long-lived sessions, and auto-saving. How many times have you filled out a form in a web page and had your information erased? It has happened to me more times than I care to remember. Sometimes it is because I was typing so fast I accidentally hit the wrong key and navigated off the page, and sometimes it is because the session on the server timed out. In all of these cases Raskin believes the application is responsible for not losing any content entered by the user.
This is a subject I was not aware existed, "cognetics". Cognetics is essentially ergonomics, but it is applied to the mind instead of the physical nature of the body. Where ergonomics might take into account the average length of human legs when building a chair, cognetics takes into account the average time it takes for the human mind to switch contexts. Raskin talk about the conscience and unconscious in length, explaining the human capacity for dealing with interfaces, and most importantly how habits are formed and can make an interface faster. Truly interesting stuff.
Laws are something I can understand! As a programmer I know a lot of laws that help me make decisions, and interface design relies on the same thing. In this case Fitt's law defines a formulae for determining the amount of time that it takes a user to move the mouse and click a button. The primary factor being that the larger the target area, the less time it takes to click the button. In the case of the Macintosh the menu-bar is at the edge of the screen, so the size of the target button is in essence larger than what you see on screen since it is impossible to move the mouse off the screen.
For you Windows users, try this experiment. Move the mouse to the File menu in any application and click it. Repeat this a few times to get an idea how long it takes. Unless you are a mouse sharpshooter you will likely overshoot the target often, then need to backtrack a little so that you can click the target. Now repeat the experiment with the command menu (is that the right term?). The command menu is on the applications title bar, just to the left of the name of the application (the menu with the minimize, maximize, and move options). I found that because the command menu was at the edge of the screen I could find and click the target in have the time. And that is all explained by Fitt's Law. Raskin covers other laws and introduces several models for finding the average time for a user to use a particular feature.
There are several other quotes I have noted in the Wave, but I want to stop here, and instead of reading this post I urge you to go out and read this book.
Wait, wait! Don't go!
I expect that many of my readers are coders and it might not seem like this posting is for coders, but it is especially for coders. I have been hacking and crafting code for fun and profit for over 20 years now. I have read all of the classic programming bibles, from the Mythical Man Month, to Design Patterns by the Gang of Four. All of them have been about writing the code, or managing the project. But all of these ignore, and rightfully so given their topics, that the success of a project depends on the user liking the product. And the user of course can't see the beautiful domain model, clean code, and vast array of automated tests that you have created. All they see is the interface.
As a coder I had no idea that interface design was a science, and instead always thought that it was an art. But it is a science, and it has nothing to do with nice looking graphics. This book taught me that.
As I read through the book, which I am still in the progress of reading, I have been posting quotes from the book on Google Wave that encapsulate the important bits for me that I know that I need to remember. If you want to read them or post your own you can find the Wave my searching for with:public by:iamroberthanson "Humane Interface". In the rest of this entry I want to share a few choice quotes from the book along with some explanation so that you can see why this book would be a valuable edition to your bookshelf.
"Your Time Is Sacred; Your Work Is Sacred"
This might seem obvious, but if it was so obvious it wouldn't be ignored so often. Raskin discussed this in some length, including why it is important to include undo/redo functionality, the importance of long-lived sessions, and auto-saving. How many times have you filled out a form in a web page and had your information erased? It has happened to me more times than I care to remember. Sometimes it is because I was typing so fast I accidentally hit the wrong key and navigated off the page, and sometimes it is because the session on the server timed out. In all of these cases Raskin believes the application is responsible for not losing any content entered by the user.
The study of the applicable, engineering scope of our mental abilities is cognitive engineering, or cognetics.
This is a subject I was not aware existed, "cognetics". Cognetics is essentially ergonomics, but it is applied to the mind instead of the physical nature of the body. Where ergonomics might take into account the average length of human legs when building a chair, cognetics takes into account the average time it takes for the human mind to switch contexts. Raskin talk about the conscience and unconscious in length, explaining the human capacity for dealing with interfaces, and most importantly how habits are formed and can make an interface faster. Truly interesting stuff.
Fitts' law explains, for example, why it is much faster to move the cursor to an Apple Macintosh–style menu that is on the edge of a display than to a Microsoft Windows–style menu that floats away from an edge.
Laws are something I can understand! As a programmer I know a lot of laws that help me make decisions, and interface design relies on the same thing. In this case Fitt's law defines a formulae for determining the amount of time that it takes a user to move the mouse and click a button. The primary factor being that the larger the target area, the less time it takes to click the button. In the case of the Macintosh the menu-bar is at the edge of the screen, so the size of the target button is in essence larger than what you see on screen since it is impossible to move the mouse off the screen.
For you Windows users, try this experiment. Move the mouse to the File menu in any application and click it. Repeat this a few times to get an idea how long it takes. Unless you are a mouse sharpshooter you will likely overshoot the target often, then need to backtrack a little so that you can click the target. Now repeat the experiment with the command menu (is that the right term?). The command menu is on the applications title bar, just to the left of the name of the application (the menu with the minimize, maximize, and move options). I found that because the command menu was at the edge of the screen I could find and click the target in have the time. And that is all explained by Fitt's Law. Raskin covers other laws and introduces several models for finding the average time for a user to use a particular feature.
There are several other quotes I have noted in the Wave, but I want to stop here, and instead of reading this post I urge you to go out and read this book.
Sunday, July 26, 2009
Managing a Remote Development Team
A friend of mine called the other day and was asking some questions about managing a development team that is separated by several time zones. I consider myself a thoughtful person, but not very quick, so the answer I provided was off the mark and not very insightful. Now that I have had a few days to ponder my answer, I believe that I now have something valuable to share.
To make my advice digestible I will break down my methods into many sections, each detailing one piece of the puzzle. I am providing them in the order that they should be implemented, because it is useless to put the cart before the horse. None of these sections is non-important, and with perhaps a few suggestions I strongly recommend implementing them all.
Before I begin to iterate my pearls of wisdom I do ask the reader to comment on what I will say here. There is always room for improvement, and I am always looking for suggestions on how to improve my process.
Pearl 1: Employ an issue tracking system.
I you don't use Jira, Bugzilla, or some other tool to track what is being worked on, then you are either headed in the wrong direction. I don't care if you have a team of 3, 30, or 300, you need to keep track of everything. My personal preference is Jira, for reasons you will see in the throughout this article, and I strongly suggest spending a little green to get it. Jira is dirt cheap for what they provide and in my opinion will provide at least a 100% return the very first year you use it. The reason for an issue tracking system is (1) it provides managers with insight as to what it being worked on, and (2) provides documentation on the work that was done. Ideally an issue will take no more than a day or two to complete, but I wouldn't get too hung up on that, the important part is to just keep track of what you are doing.
Pearl 2: Version control your code base.
No excuses, get that code into a good version control solution. Subversion is a great choice and has really good tool support, making it perhaps the best solution out there. If you use CVS, get rid of it, it lacks atomic commits, and atomic commits are very important. If you don't know what an atomic commit is, then find out. It is important to really understand how to use your version control system, and what the best practices are. You should always create rules around how to use your version control system, and my number one rule it to include the issue key from the issue tracking system with every commit. You must be able to take any line of code and trace it back to a task and the developer that wrote it.
Pearl 3: Define some coding standards
You don't need to write a book, but you must have some guidelines. Determine what is important and make a standard. For my team I require no tabs in source code, no cuddled elses, javadocs for every class declaration and method, expressive variable names, and more. If you are writing code in Java you should employ Checkstyle. Checkstyle is a tool that takes a set of rules and verifies that the code is in compliance. i recommend starting with one of the rules files that ship with Checkstyle, then tweak it ti fit your style. Checkstyle is integrated with IDE's and build tools, so your developers will have no excuses for not following the rules. Note that it is not so important to have good rules, just as long as you have some rules.
Pearl 4: Code review everything
There are so many benefits to performing code reviews; verifying compliance with standards, cross-training, less bugs, and simply better code. The problem with doing reviews is that it can be difficult to discipline your developers into performing them, and even if they are performed there is often no evidence that they occurred. This is where I need to recommend another tool, Crucible and its sister product FishEye. FishEye is a web application that allows you to easily search and browse your source code repository. It is an extremely useful tool in its own right, and the larger and older your code base, the more valuable it becomes for visualizing code changes and searching for reusable code. Crucible is a code review tool that uses FishEye's remote APIs to make committed code available for review. Crucible allows a moderator to kick off reviews and manages the overall process or performing the review. And most important it saves all of the comments from the review, providing additional documentation on the change that was made. There is also an opportunity for synergy here. Jira has FisyEye support built-in, so as long as every source control commit has the Jira task ID in the comment, Jira will be able to show you the code changes performed for each task.
Time to implement
The best way to implement this is to take your best developer and put her in charge of the standards. Allow her to define the coding standard, and then make her do the majority of the code reviews. The perfect person for this is one that is very opinionated on what the "right way" of developing a project is, yet will listen to other ideas and is willing to change what the "right way" means.
If you stick with this plan you will slowly find that all of the developers start coding the same way and that the general level of code quality will increase. And once everyone is working as a team and following the same rules, you then tweak the rules. Get rid of the rules that don't work, and add new rules that increase the quality even further. This is ultimately the key to the whole thing, and you should never stop changing the rules.
To make my advice digestible I will break down my methods into many sections, each detailing one piece of the puzzle. I am providing them in the order that they should be implemented, because it is useless to put the cart before the horse. None of these sections is non-important, and with perhaps a few suggestions I strongly recommend implementing them all.
Before I begin to iterate my pearls of wisdom I do ask the reader to comment on what I will say here. There is always room for improvement, and I am always looking for suggestions on how to improve my process.
Pearl 1: Employ an issue tracking system.
I you don't use Jira, Bugzilla, or some other tool to track what is being worked on, then you are either headed in the wrong direction. I don't care if you have a team of 3, 30, or 300, you need to keep track of everything. My personal preference is Jira, for reasons you will see in the throughout this article, and I strongly suggest spending a little green to get it. Jira is dirt cheap for what they provide and in my opinion will provide at least a 100% return the very first year you use it. The reason for an issue tracking system is (1) it provides managers with insight as to what it being worked on, and (2) provides documentation on the work that was done. Ideally an issue will take no more than a day or two to complete, but I wouldn't get too hung up on that, the important part is to just keep track of what you are doing.
Pearl 2: Version control your code base.
No excuses, get that code into a good version control solution. Subversion is a great choice and has really good tool support, making it perhaps the best solution out there. If you use CVS, get rid of it, it lacks atomic commits, and atomic commits are very important. If you don't know what an atomic commit is, then find out. It is important to really understand how to use your version control system, and what the best practices are. You should always create rules around how to use your version control system, and my number one rule it to include the issue key from the issue tracking system with every commit. You must be able to take any line of code and trace it back to a task and the developer that wrote it.
Pearl 3: Define some coding standards
You don't need to write a book, but you must have some guidelines. Determine what is important and make a standard. For my team I require no tabs in source code, no cuddled elses, javadocs for every class declaration and method, expressive variable names, and more. If you are writing code in Java you should employ Checkstyle. Checkstyle is a tool that takes a set of rules and verifies that the code is in compliance. i recommend starting with one of the rules files that ship with Checkstyle, then tweak it ti fit your style. Checkstyle is integrated with IDE's and build tools, so your developers will have no excuses for not following the rules. Note that it is not so important to have good rules, just as long as you have some rules.
Pearl 4: Code review everything
There are so many benefits to performing code reviews; verifying compliance with standards, cross-training, less bugs, and simply better code. The problem with doing reviews is that it can be difficult to discipline your developers into performing them, and even if they are performed there is often no evidence that they occurred. This is where I need to recommend another tool, Crucible and its sister product FishEye. FishEye is a web application that allows you to easily search and browse your source code repository. It is an extremely useful tool in its own right, and the larger and older your code base, the more valuable it becomes for visualizing code changes and searching for reusable code. Crucible is a code review tool that uses FishEye's remote APIs to make committed code available for review. Crucible allows a moderator to kick off reviews and manages the overall process or performing the review. And most important it saves all of the comments from the review, providing additional documentation on the change that was made. There is also an opportunity for synergy here. Jira has FisyEye support built-in, so as long as every source control commit has the Jira task ID in the comment, Jira will be able to show you the code changes performed for each task.
Time to implement
The best way to implement this is to take your best developer and put her in charge of the standards. Allow her to define the coding standard, and then make her do the majority of the code reviews. The perfect person for this is one that is very opinionated on what the "right way" of developing a project is, yet will listen to other ideas and is willing to change what the "right way" means.
If you stick with this plan you will slowly find that all of the developers start coding the same way and that the general level of code quality will increase. And once everyone is working as a team and following the same rules, you then tweak the rules. Get rid of the rules that don't work, and add new rules that increase the quality even further. This is ultimately the key to the whole thing, and you should never stop changing the rules.
Saturday, May 16, 2009
Do you really need to test that?
We all know Kent Beck. The co-creator of JUnit, one of the founding fathers of the Agile Manifesto, author of several eXtreme Programming books, just to highlight a few. Now that Kent has spent a decade telling us all to test everything... now he says, it is ok to skip testing.
I'll let that sink in a bit.
What he is basically saying is that it is ok for the kids to play in the street, if they feel that it is safe. Of course Kent is a big kid, so he will use his experience to determine if it is ok for him to play in the street. But what about the kids that don't know better? You know who they are. They are the kids that climb the tree without thinking about how they are going to get down. They are the kids that lock themselves in the closet without thinking about how they are going to get out.
Kids will be kids. They will make poor decisions if you give them the chance. That is why there are parents. Our job is to make sure that they don't make stupid decisions. Or perhaps we let them make bad decisions to teach them a lesson, just as long as we can control the environment to ensure that nobody gets seriously hurt.
So now is the time to decide if you are a the parent or a the kid. And if you think that you are the parent, half of you are probably wrong. That is the nature of the child, to think they know everything.
One way to measure if you are the parent or the kid is to use the Dreyfus Model of Skill Acquisition. If you follow Andy Hunt, you may have seen him speak and write about this. The model is basically a set of five stages that you progress through from novice to master. It helps explain why novices need lots of rules, and why experts don't think they apply to them.
On the Dreyful Model I often rank myself at a 4 1/2, depending on the subject matter of course. It can be an interesting exercise to rank yourself on the scale, then let your friends rank you to see if you meet your expectations of greatness. Likely you won't, but that is ok, it is in our nature to be overly self-confident.
Now back to testing. Is it really ok to skip testing? Kent thinks so, but I wonder if the followers of the TDD "faith" think the same. In many shops there is no ambiguity, there are only absolutes. You must test they say, but do you? Kent Beck thinks it is a judgment call.
Now I don't have the right answer other than there is no black and white, instead it is all gray. You should acknowledge that, and not immediately attack someone who says that they didn't write a test. Instead ask them their reasoning. Perhaps it is a good reason, perhaps not, but don't come to conclusions.
I'll let that sink in a bit.
What he is basically saying is that it is ok for the kids to play in the street, if they feel that it is safe. Of course Kent is a big kid, so he will use his experience to determine if it is ok for him to play in the street. But what about the kids that don't know better? You know who they are. They are the kids that climb the tree without thinking about how they are going to get down. They are the kids that lock themselves in the closet without thinking about how they are going to get out.
Kids will be kids. They will make poor decisions if you give them the chance. That is why there are parents. Our job is to make sure that they don't make stupid decisions. Or perhaps we let them make bad decisions to teach them a lesson, just as long as we can control the environment to ensure that nobody gets seriously hurt.
So now is the time to decide if you are a the parent or a the kid. And if you think that you are the parent, half of you are probably wrong. That is the nature of the child, to think they know everything.
One way to measure if you are the parent or the kid is to use the Dreyfus Model of Skill Acquisition. If you follow Andy Hunt, you may have seen him speak and write about this. The model is basically a set of five stages that you progress through from novice to master. It helps explain why novices need lots of rules, and why experts don't think they apply to them.
On the Dreyful Model I often rank myself at a 4 1/2, depending on the subject matter of course. It can be an interesting exercise to rank yourself on the scale, then let your friends rank you to see if you meet your expectations of greatness. Likely you won't, but that is ok, it is in our nature to be overly self-confident.
Now back to testing. Is it really ok to skip testing? Kent thinks so, but I wonder if the followers of the TDD "faith" think the same. In many shops there is no ambiguity, there are only absolutes. You must test they say, but do you? Kent Beck thinks it is a judgment call.
Now I don't have the right answer other than there is no black and white, instead it is all gray. You should acknowledge that, and not immediately attack someone who says that they didn't write a test. Instead ask them their reasoning. Perhaps it is a good reason, perhaps not, but don't come to conclusions.
Wednesday, May 13, 2009
Software Craftsmanship
It has been a while since I sat down to write something, but that is because I have been caught up in learning. In March I presented at ETE in Philadelphia, and during my stay there I met a programming hippy Corey Haines. Corey was just like all of us, writing code for his day job, and like some of us enjoyed it. In December he lost his job, and with some money in the bank and a lot of free time decided to invest in himself. He began what became to be an adventure in pair programming, He now spends his days travelling the country, pair programming with anyone that will give him a place to stay and some code to work on. His journey is inspiring.
Now, this isn't a story about Corey, it is about software. In particular it is about good software. Corey, like many of us cares about the quality of his code. In his case he cares so much that he decided to pair with perfect strangers in order to increase his knowledge. While many of us can't afford to travel the country like Corey, or just find staying with strangers frightening, we find other ways to increase our knowledge.
So this is a story about writing good software. It is about craftsmanship. In December a manifesto was drafted. It was drafted by professional programmers that felt the Agile Manifesto didn't go far enough. They stated that working software was good, but well crafted software was better. That responding to change, while a virtue, isn't as good as steadily adding value. Out of this congress came the Software Craftsmanship Manifesto. It is a declaration of professionalism and quality, and I have put my name to it, along with thousands of others.
So what? So some coders put together a web page, called it a manifesto, and a bunch of other coders bought into it. I think it is more than that. I think our craft is changing, for the better. The best I have seen it described is in a presentation by Uncle Bob Martin. I recommend that you take a look, it is well worth the 60 minutes spend watching the video.
References:
http://www.infoq.com/presentations/craftmanship-ethics
http://www.infoq.com/news/2009/03/software_craftsmanship
http://manifesto.softwarecraftsmanship.org/
http://www.phillyemergingtech.com/
http://agilemanifesto.org/
http://www.coreyhaines.com/
http://en.wikipedia.org/wiki/Pair_programming
Now, this isn't a story about Corey, it is about software. In particular it is about good software. Corey, like many of us cares about the quality of his code. In his case he cares so much that he decided to pair with perfect strangers in order to increase his knowledge. While many of us can't afford to travel the country like Corey, or just find staying with strangers frightening, we find other ways to increase our knowledge.
So this is a story about writing good software. It is about craftsmanship. In December a manifesto was drafted. It was drafted by professional programmers that felt the Agile Manifesto didn't go far enough. They stated that working software was good, but well crafted software was better. That responding to change, while a virtue, isn't as good as steadily adding value. Out of this congress came the Software Craftsmanship Manifesto. It is a declaration of professionalism and quality, and I have put my name to it, along with thousands of others.
So what? So some coders put together a web page, called it a manifesto, and a bunch of other coders bought into it. I think it is more than that. I think our craft is changing, for the better. The best I have seen it described is in a presentation by Uncle Bob Martin. I recommend that you take a look, it is well worth the 60 minutes spend watching the video.
References:
http://www.infoq.com/presentations/craftmanship-ethics
http://www.infoq.com/news/2009/03/software_craftsmanship
http://manifesto.softwarecraftsmanship.org/
http://www.phillyemergingtech.com/
http://agilemanifesto.org/
http://www.coreyhaines.com/
http://en.wikipedia.org/wiki/Pair_programming
Subscribe to:
Posts (Atom)