At every Alt .Net event I've been to (all three of them but I'm still kinda new to this) as well as every conference, it seems like the vast majority of the attendees are developers. While we're there, we have sessions on things like "how to convince project managers to use Agile" and "how to talk to business people" and stuff like that. Then we return to our jobs and try to convince these people that we're right or that code quality is important or that unit tests help improve your product or other things that are obvious to us (especially after two hours of discussion). So here's my question:
WHY DON'T THE BUSINESS PEOPLE ATTEND OUR CONFERENCES?????
whoa, I just had an epiphany:
WHY DON'T WE SOFTWARE PEOPLE ATTEND THE BUSINESS CONFERENCES????
It seems like we're trying to figure out how to communicate with the "other side" that is the business. We are saying that we value communication, engagement, and people over process, however all we're doing is creating a process for trying to communicate with them. Isn't this a violation of our own principles? Certainly seems like it to me.
It works both ways, people
Instead of just talking to each other about how we communicate with the business people (and I assume the MBA conference probably has similar ideas about talking to software people), why don't we practice what we preach and bring some of these business people to our conferences and directly engage them in this whole communication thing? We can tell them how we communicate and what our needs are and what is important to us and most importantly, why these things are important. In turn, they can tell us the same thing from their perspective. I think that this would be infinitely superior to what we do now.
If you build it, they will come (and they've built it and we're sitting around)
On the flip side of this, how many of us developers actually attend any business-oriented conferences? Have any of us? What about presenting a session at them? Anyone do that? I certainly haven't and I have only myself to blame for this. I think it's time for us as a community to take action and not only bring the business folks and managers into our movement, but actively reach out to them and approach them in their community as well and let them bring us into their world for a change. Anyone out there agree with me? Anyone have any ideas on how we can do this?
Showing posts with label Agile. Show all posts
Showing posts with label Agile. Show all posts
Thursday, June 26, 2008
Wednesday, May 28, 2008
Why Elegant Code doesn't get Agile
This blog post seems to insinuate that Agile does not work. I believe that their David Starr (correction: I directed this at all of Elegant Code when I should have been specific to the poster. Apologies for this oversight on my part) conclusions are flawed and that they truly don't understand that Agile is an idea and not a process. I think a better title of this post would be "why being dogmatic about Agile doesn't really work" or "why people who do things because that's what you do in Scrum doesn't really work" or some such. By making this blanket statement about Agile not working, they are both ignoring the many success stories that Agile has and betraying their own ignorance of the Agile process.
"Agile supports the idea of frequent delivery of value to customers."
Let's look at shipping software for a minute. Where in the Agile Manifesto does it say "You have to ship software every two weeks" or anything like that? Go ahead, look for it. I'll wait. Didn't find it? That's because it isn't there, and it isn't there for a reason. That reason (I generally believe) is that shipping software to customers every two weeks is a retarded-stupid idea for all of the reasons that the article goes into. I'll summarize them here:
DELIVERING WORKING SOFTWARE IS NOT THE SAME AS SHIPPING A PRODUCT!!!!!!!!!!!!!!!!!
That's right, you can deliver working code constantly. You can deliver it to sales so that they can preview what they're going to sell. You can deliver it to your customer proxy to verify that you have correctly implemented the features that you need. You can deliver it to your sprint demo so that the rest of the world can see it work and know that you're going well. You can deliver it to your project manager so that he doesn't have a heart attack every sprint because the software doesn't work. BUT YOU DON'T HAVE TO SHIP IT. Just because you CAN ship something doesn't mean that you should.
So why do we deliver working code in the first place if we're not going to ship it?
Because in Agile, we want rapid feedback. It is much, much easier to fix something right after you build it than it is to fix it three months after you build it. The sooner you know that you need to change something, the easier it is. For example, let's say that your QA department is one sprint behind your development in their testing. On my team, we average about ten builds per day (utilizing our CI tools at the time of checkin, but if you count personal builds it's probably a lot more). Our sprint is three weeks, which gives us about 14 days of development on average (adjusted for the time spent on code review, sprint planning, sprint demos, holidays, etc.). With ten builds per day, that means at a minimum, QA is finding a bug that has existed for 140 builds. Other functionality may be built on top of it. It may have dependencies on other parts of your code. Finally, where the hell is that bug occurring, given that maybe you've worked on a dozen different objects since the bug was introduced? You'll have to hunt for it, and that takes time.
So Elegant Code has missed the boat on this one: They're assuming that delivering working software means "shipping it to the customer" when this is absolutely not the case. They're jumping to that conclusion. Maybe I should write "delivering software means shipping it to the customer" on a mat on the floor, and they could "jump" to it. I'll make a million dollars!
"[The] organization [you're shipping to] must actually be able to receive the update without tipping over"
This is their second argument against Agile, and (coincidentally enough) their second mistake. I've added some words to clarify their point so that it isn't taken out of context, but I would encourage you to read the article so that you don't think I'm making this up. That is not my intent. Anyway, we aren't shipping the software every two weeks, so the customer only gets their release when they actually want it. The strength of Agile is twofold on this:
In fact, the problems that they describe are actually readily solved by Agility: Documentation team needs another week or two? No problem. At least we have a working piece of software for them to document against. We either add something small that they can easily document, refactor the code against our //TODO list, or branch and keep going with the intent to release a branch. IT says you need a week-long burn in test? Or what about a month long peer-review process like my company? Not a problem either, we just branch and continue working on the trunk, fixing anything that comes up in the branch (which is what we're releasing) and merge those fixes with the trunk one at a time as soon as they're finished so that integration is easier.
Ultimately,Elegant Code David Starr has not missed the boat, but unfortunately the boat that they caught
was the failboat. Their argument sounds good on the surface, but they have failed to realize that Agile's ability to handle change combined with a rapid feedback cycle actually deals quite nicely with all the problems that they are describing. I'd like to close with a question: If Agile doesn't work, what does? Huh? Can't find that in the article? It's in the same place in the article as "shipping software" is in the Agile Manifesto (i.e. it's not there). I think Elegant Code needs to do some more studying on what Agile is and what it truly means, as well as looking at some success and failure stories before they suggest that Agile has failed because you can ship too frequently if you're dogmatic about it.
"Agile supports the idea of frequent delivery of value to customers."
Let's look at shipping software for a minute. Where in the Agile Manifesto does it say "You have to ship software every two weeks" or anything like that? Go ahead, look for it. I'll wait. Didn't find it? That's because it isn't there, and it isn't there for a reason. That reason (I generally believe) is that shipping software to customers every two weeks is a retarded-stupid idea for all of the reasons that the article goes into. I'll summarize them here:
- Sales can't keep up with that release cycle
- Training can't keep up with that release cycle
- Documentation is often not available at that frequency
- Any type of release-preparation can't be done (burning CD's, peer-review, post-mortems, etc)
- Software with a high amount of overhead to upgrade won't allow for this (think SAP or Sharepoint or some such product)
- Most customers don't want a new version every two weeks because they'll have to upgrade and re-train their employees
- This pace is not sustainable, which is something that is, in fact, on the Agile Manifesto ("Agile process promote sustainable development")
DELIVERING WORKING SOFTWARE IS NOT THE SAME AS SHIPPING A PRODUCT!!!!!!!!!!!!!!!!!
That's right, you can deliver working code constantly. You can deliver it to sales so that they can preview what they're going to sell. You can deliver it to your customer proxy to verify that you have correctly implemented the features that you need. You can deliver it to your sprint demo so that the rest of the world can see it work and know that you're going well. You can deliver it to your project manager so that he doesn't have a heart attack every sprint because the software doesn't work. BUT YOU DON'T HAVE TO SHIP IT. Just because you CAN ship something doesn't mean that you should.
So why do we deliver working code in the first place if we're not going to ship it?
Because in Agile, we want rapid feedback. It is much, much easier to fix something right after you build it than it is to fix it three months after you build it. The sooner you know that you need to change something, the easier it is. For example, let's say that your QA department is one sprint behind your development in their testing. On my team, we average about ten builds per day (utilizing our CI tools at the time of checkin, but if you count personal builds it's probably a lot more). Our sprint is three weeks, which gives us about 14 days of development on average (adjusted for the time spent on code review, sprint planning, sprint demos, holidays, etc.). With ten builds per day, that means at a minimum, QA is finding a bug that has existed for 140 builds. Other functionality may be built on top of it. It may have dependencies on other parts of your code. Finally, where the hell is that bug occurring, given that maybe you've worked on a dozen different objects since the bug was introduced? You'll have to hunt for it, and that takes time.
So Elegant Code has missed the boat on this one: They're assuming that delivering working software means "shipping it to the customer" when this is absolutely not the case. They're jumping to that conclusion. Maybe I should write "delivering software means shipping it to the customer" on a mat on the floor, and they could "jump" to it. I'll make a million dollars!
"[The] organization [you're shipping to] must actually be able to receive the update without tipping over"
This is their second argument against Agile, and (coincidentally enough) their second mistake. I've added some words to clarify their point so that it isn't taken out of context, but I would encourage you to read the article so that you don't think I'm making this up. That is not my intent. Anyway, we aren't shipping the software every two weeks, so the customer only gets their release when they actually want it. The strength of Agile is twofold on this:
- We can show them what they're going to get more easily because the software is always working. We can give them a beta whenever they're ready for it so they can start coding against our API if they want to. If they don't like our API, we can change it easily and ship a new version. They can see if the features they want are actually going to work the way they want. They can give us rapid feedback, which is very important to our ability to deliver them the features that they want.
- We don't have to ship it to them "on time" either, because when you can ship every two weeks, "on time" starts to mean whatever you want it to mean. If they aren't ready for a month or two, we can delay and continue to add value (or just branch the code) and ship when they're ready to receive. If they suddenly get an upgrade to their database and our code is going to break it if we add Oracle support, we can release a working version prior to adding Oracle support. BizTalk no longer supports a feature? Prioritize that as a sprint item and ship two weeks later. Try doing that in waterfall.
In fact, the problems that they describe are actually readily solved by Agility: Documentation team needs another week or two? No problem. At least we have a working piece of software for them to document against. We either add something small that they can easily document, refactor the code against our //TODO list, or branch and keep going with the intent to release a branch. IT says you need a week-long burn in test? Or what about a month long peer-review process like my company? Not a problem either, we just branch and continue working on the trunk, fixing anything that comes up in the branch (which is what we're releasing) and merge those fixes with the trunk one at a time as soon as they're finished so that integration is easier.
Ultimately,
was the failboat. Their argument sounds good on the surface, but they have failed to realize that Agile's ability to handle change combined with a rapid feedback cycle actually deals quite nicely with all the problems that they are describing. I'd like to close with a question: If Agile doesn't work, what does? Huh? Can't find that in the article? It's in the same place in the article as "shipping software" is in the Agile Manifesto (i.e. it's not there). I think Elegant Code needs to do some more studying on what Agile is and what it truly means, as well as looking at some success and failure stories before they suggest that Agile has failed because you can ship too frequently if you're dogmatic about it.
Monday, April 21, 2008
My brain is full and my liver is angry
So the Alt .Net open spaces event has concluded. This is the best conference I've ever been to (with DevTeach Vancouver being a close second) for a variety of reasons that I will get into later, but let me first start out with a brief description of what exactly this type of event is.
Format
First, there is no agenda, no speakers submit their sessions for approval, there is no keynote, and there isn't even a fixed list of topics. Everyone has equal input and there is collective decision making in what occurs. You start out by proposing topics and discussing them and then people decide what topics they most want to talk about. These become the sessions that you can go to.
Each session can be whatever the people want them to be. If the sessions are small, everyone can just discuss the topics. If they are larger, a fishbowl format is used, where some number of people n are sitting in n+1 chairs such that one chair is always empty. Anyone may go up and sit in the empty chair at any time and the person who has been there the longest has to get up. I like this format because everyone gets a change to speak and contribute. Sessions aren't death by powerpoint and they aren't some company just trying to sell you something.
People
A lot of people were there. Some of them were new to Alt.Net and were interested in learning more about the movement. There were quite a few people from Microsoft, including ScottGu, Scott Hanselman, and many others. Also, a lot of the usual Alt.Net people were there (most of whom are bloggers that I link to on my home page). I missed Justice Gray and I hope that he will be there for the next one (study your VB 6 hard, Justice, so you can be an MVP). I also got to meet a few local developers that I hope to stay in touch with (including one from my own company but a different division than I work for). To everyone whom I gave a business card: please keep in touch. To everyone who gave me a business card: I'll try to get back to all of you as soon as I can.
Topics
So many things were talked about that my head is spinning. There was discussion and the exchange of ideas pretty much nonstop throughout this conference, so I'll try to go over a few of the highlights that I remember.
Spec#
This was an interesting demonstration. Greg Young has long hyped the coming of Spec# because it enables true design-by-contract where contracts can be explicitly specified at design time and verified at compile time. This forces you to ensure that your code is 'correct' when it is built. I had my doubts (the halting problem comes to mind), but now that I've actually seen it work I think it's going to be a great tool. I hope that all eight of you who read my blog will join the 30,000 or so that read Hanselman's blog in sending emails to Microsoft demanding the release of Spec#.
Are we innovating or just porting?
This talk was about all the new tools in the Alt .Net community and asking if we're actually creating any truly "new" tools or if we're just porting them from the Java community. It was a great discussion with a lot of people saying a lot of things that I wish I could write more specifically about. Someone videotaped this, I hope that it gets posted somewhere.
How to talk to suits
Very interesting talk about how to sell Agile to management but also some good information about how to talk to business people in general. Something that was brought up was the idea of having respect and trust for each other which is something that I think is lacking in a lot of places. Some ideas for helping to "sell" Agile was to present different practices as a solution for existing pains that a company is feeling. Lots of good information here. I was also surprised by the number of consultants at this talk, it was well over 75% of the group.
Has software development failed?
A good talk about the current state of software development projects. There have been some very notable failures in the industry over the years. I brought up my question of "are we all wrong" and got some good discussion going on there.
Javascript- it's not just the bastard step-child of your web app
This was a cool talk. A lot of people tend to treat javascript like some sort of second class citizen. It's there, but it isn't too important. As a result, there aren't a lot of test frameworks and established patterns out there for javascript and its code quality often is sub-par. While there are some great frameworks out there (some of which I need to take a fresh look at), there is a real need for improving the tools, particularly now that javascript is becoming more of a tool for the presentation layer and contains business logic. It is a real programming language so all the rules of good design apply to it and I think people largely haven't realized that until recently. Justin Angel had a great tool also for running javascript unit tests at build time. It wasn't quite what I would want but it is still very slick and would definitely be useful.
Education in the industry
This was a great point that Scott Hanselman mentioned at least a dozen times and I still think he could have said it more without it being overkill because it's that important. There is a significant lack of education in basic software engineering principles out there in schools. Computer Science programs teach algorithms, O(n), data structures, and polymorphism. Those things are super-important to developing software. However, what's missing is things like concepts in good object-oriented design, how to test your software, unit testing, refactoring, patterns, and version control. He mentioned speaking to local schools about your career and software development in general. I think he's right, and I intend to actually go out and do something about it. I'm not sure what yet, but I did talk to a few friends of mine who happened to be students at digipen. I ran into them on the last day and they asked me about the conference and we ended up talking for an hour or so. I'll post more in the future as I continue to follow up on this.
Overall, this was an awesome conference. There was a lot of good dialog and exchange of knowledge as well as a lot of respect for everyone there. Someone there said that we're all leaders (might have been David Laribee who said that) and so we need to go out and lead. I'm going to go out and lead, and I'm going to challenge everyone who is reading this to do the same.
Also, if you're not at the next open spaces, you'd better be dead or in jail, and if you're in jail then break out.
Also, if you are interested in seeing some more of it, Jeff Palermo made some videos that are posted over on his blog.
Format
First, there is no agenda, no speakers submit their sessions for approval, there is no keynote, and there isn't even a fixed list of topics. Everyone has equal input and there is collective decision making in what occurs. You start out by proposing topics and discussing them and then people decide what topics they most want to talk about. These become the sessions that you can go to.
Each session can be whatever the people want them to be. If the sessions are small, everyone can just discuss the topics. If they are larger, a fishbowl format is used, where some number of people n are sitting in n+1 chairs such that one chair is always empty. Anyone may go up and sit in the empty chair at any time and the person who has been there the longest has to get up. I like this format because everyone gets a change to speak and contribute. Sessions aren't death by powerpoint and they aren't some company just trying to sell you something.
People
A lot of people were there. Some of them were new to Alt.Net and were interested in learning more about the movement. There were quite a few people from Microsoft, including ScottGu, Scott Hanselman, and many others. Also, a lot of the usual Alt.Net people were there (most of whom are bloggers that I link to on my home page). I missed Justice Gray and I hope that he will be there for the next one (study your VB 6 hard, Justice, so you can be an MVP). I also got to meet a few local developers that I hope to stay in touch with (including one from my own company but a different division than I work for). To everyone whom I gave a business card: please keep in touch. To everyone who gave me a business card: I'll try to get back to all of you as soon as I can.
Topics
So many things were talked about that my head is spinning. There was discussion and the exchange of ideas pretty much nonstop throughout this conference, so I'll try to go over a few of the highlights that I remember.
Spec#
This was an interesting demonstration. Greg Young has long hyped the coming of Spec# because it enables true design-by-contract where contracts can be explicitly specified at design time and verified at compile time. This forces you to ensure that your code is 'correct' when it is built. I had my doubts (the halting problem comes to mind), but now that I've actually seen it work I think it's going to be a great tool. I hope that all eight of you who read my blog will join the 30,000 or so that read Hanselman's blog in sending emails to Microsoft demanding the release of Spec#.
Are we innovating or just porting?
This talk was about all the new tools in the Alt .Net community and asking if we're actually creating any truly "new" tools or if we're just porting them from the Java community. It was a great discussion with a lot of people saying a lot of things that I wish I could write more specifically about. Someone videotaped this, I hope that it gets posted somewhere.
How to talk to suits
Very interesting talk about how to sell Agile to management but also some good information about how to talk to business people in general. Something that was brought up was the idea of having respect and trust for each other which is something that I think is lacking in a lot of places. Some ideas for helping to "sell" Agile was to present different practices as a solution for existing pains that a company is feeling. Lots of good information here. I was also surprised by the number of consultants at this talk, it was well over 75% of the group.
Has software development failed?
A good talk about the current state of software development projects. There have been some very notable failures in the industry over the years. I brought up my question of "are we all wrong" and got some good discussion going on there.
Javascript- it's not just the bastard step-child of your web app
This was a cool talk. A lot of people tend to treat javascript like some sort of second class citizen. It's there, but it isn't too important. As a result, there aren't a lot of test frameworks and established patterns out there for javascript and its code quality often is sub-par. While there are some great frameworks out there (some of which I need to take a fresh look at), there is a real need for improving the tools, particularly now that javascript is becoming more of a tool for the presentation layer and contains business logic. It is a real programming language so all the rules of good design apply to it and I think people largely haven't realized that until recently. Justin Angel had a great tool also for running javascript unit tests at build time. It wasn't quite what I would want but it is still very slick and would definitely be useful.
Education in the industry
This was a great point that Scott Hanselman mentioned at least a dozen times and I still think he could have said it more without it being overkill because it's that important. There is a significant lack of education in basic software engineering principles out there in schools. Computer Science programs teach algorithms, O(n), data structures, and polymorphism. Those things are super-important to developing software. However, what's missing is things like concepts in good object-oriented design, how to test your software, unit testing, refactoring, patterns, and version control. He mentioned speaking to local schools about your career and software development in general. I think he's right, and I intend to actually go out and do something about it. I'm not sure what yet, but I did talk to a few friends of mine who happened to be students at digipen. I ran into them on the last day and they asked me about the conference and we ended up talking for an hour or so. I'll post more in the future as I continue to follow up on this.
Overall, this was an awesome conference. There was a lot of good dialog and exchange of knowledge as well as a lot of respect for everyone there. Someone there said that we're all leaders (might have been David Laribee who said that) and so we need to go out and lead. I'm going to go out and lead, and I'm going to challenge everyone who is reading this to do the same.
Also, if you're not at the next open spaces, you'd better be dead or in jail, and if you're in jail then break out.
Also, if you are interested in seeing some more of it, Jeff Palermo made some videos that are posted over on his blog.
Tuesday, April 1, 2008
Checkout rules speed up TeamCity builds a lot
I discovered something interesting today: TeamCity allows you customize what folders are checked out from your source control (we're using subversion). When we were building before, the actual build took about 5 seconds or so but the total length of time was on average a minute and a half. People complained about this and didn't lieke doing personal builds because it took too long (personal builds allow you to send a build to TeamCity and have it try to build with your updates before committing your code. This helps stop people from committing breaking changes). I found that the reason it was taking so long is that we have a lot of stuff under version control, such as our database, the QA test projects, some tools projects, as well as a bunch of other random crap that, while important to the whole project, are not directly used by the particular build configuration we care about for the website. So, after reading the manual, I discovered that I can restrict TeamCity to only check out certain directories. Here's what I did:
My svn root for my project (this is not my real svn tree, duh) is at https://127.0.0.1:8080/projects/trunk and the various parts of the application live in sub folders. I therefore have the following:
https://127.0.0.1:8080/projects/trunk/Application - our web application
https://127.0.0.1:8080/projects/trunk/Database - the database scripts
https://127.0.0.1:8080/projects/trunk/Externals - things like Rhino, MbUnit, etc.
https://127.0.0.1:8080/projects/trunk/Tools - useful tools that we write for application admin stuff
https://127.0.0.1:8080/projects/trunk/QA - our QA department's test stuff (BVT, regression, etc)
So in order to build our web application, everything we need is in Application and Externals. However, I can't just point TeamCity to https://127.0.0.1:8080/projects/trunk/Application because then I don't get Externals. I also can't just have an externals directory on my build agents because then I have to maintain them in multiple places (DRY principle- it's not just for code; it applies to project structure and build scripts too). So, I have to check out https://127.0.0.1:8080/projects/trunk which gives me about 100mb of extra crap that I don't need to build the web application. How do I deal with this?
Under TeamCity's project configuration on the Version Control Settings section, there is a thing that says "edit checkout rules" that, when clicked, will allow you to apply rules to what gets checked out. I clicked it and here is how it works:
You put each rule on its own line. A rule starts with either a + or a -, with + meaning to check out the thing and - meaning not to check it out. You would make rules relative to the root directory, so since my version control settings for the VCS root is set to https://127.0.0.1:8080/projects/trunk, I have to make all my rules relative to that path. Therefore, to exclude Database and save about 45 seconds of checkout time, I add a rule that restricts checkout of that directory. Since the directory is https://127.0.0.1:8080/projects/trunk/Database, I do this:
-:Database
and it now ignores the database (I believe that these are case sensitive). I applied a few more rules and now all that is checked out is https://127.0.0.1:8080/projects/trunk/Application and https://127.0.0.1:8080/projects/trunk/Externals for my main application build. This reduced my build time to about nine seconds on average. Much better. There are other things that you can do here with checkout rules also but I'm not actively using any of them yet.
I have been using TeamCity for a while now, I strongly suggest you check it out. There is a free version with limited numbers of Users (20), Build Agents (3), and Build Configurations (20). You can buy additional build agents individually or you can buy the full version which gives you more features. Check it out here: http://www.jetbrains.com/teamcity/
My svn root for my project (this is not my real svn tree, duh) is at https://127.0.0.1:8080/projects/trunk and the various parts of the application live in sub folders. I therefore have the following:
https://127.0.0.1:8080/projects/trunk/Application - our web application
https://127.0.0.1:8080/projects/trunk/Database - the database scripts
https://127.0.0.1:8080/projects/trunk/Externals - things like Rhino, MbUnit, etc.
https://127.0.0.1:8080/projects/trunk/Tools - useful tools that we write for application admin stuff
https://127.0.0.1:8080/projects/trunk/QA - our QA department's test stuff (BVT, regression, etc)
So in order to build our web application, everything we need is in Application and Externals. However, I can't just point TeamCity to https://127.0.0.1:8080/projects/trunk/Application because then I don't get Externals. I also can't just have an externals directory on my build agents because then I have to maintain them in multiple places (DRY principle- it's not just for code; it applies to project structure and build scripts too). So, I have to check out https://127.0.0.1:8080/projects/trunk which gives me about 100mb of extra crap that I don't need to build the web application. How do I deal with this?
Under TeamCity's project configuration on the Version Control Settings section, there is a thing that says "edit checkout rules" that, when clicked, will allow you to apply rules to what gets checked out. I clicked it and here is how it works:
You put each rule on its own line. A rule starts with either a + or a -, with + meaning to check out the thing and - meaning not to check it out. You would make rules relative to the root directory, so since my version control settings for the VCS root is set to https://127.0.0.1:8080/projects/trunk, I have to make all my rules relative to that path. Therefore, to exclude Database and save about 45 seconds of checkout time, I add a rule that restricts checkout of that directory. Since the directory is https://127.0.0.1:8080/projects/trunk/Database, I do this:
-:Database
and it now ignores the database (I believe that these are case sensitive). I applied a few more rules and now all that is checked out is https://127.0.0.1:8080/projects/trunk/Application and https://127.0.0.1:8080/projects/trunk/Externals for my main application build. This reduced my build time to about nine seconds on average. Much better. There are other things that you can do here with checkout rules also but I'm not actively using any of them yet.
I have been using TeamCity for a while now, I strongly suggest you check it out. There is a free version with limited numbers of Users (20), Build Agents (3), and Build Configurations (20). You can buy additional build agents individually or you can buy the full version which gives you more features. Check it out here: http://www.jetbrains.com/teamcity/
Wednesday, March 5, 2008
To those who want to hack it together just to make the demo work - please slap yourself
I'd like to talk a bit about the sprint demo today. Jimmy Bogard has an interesting post about letting the customer drive the demo. I think this a great idea, particularly later in the project cycle. I'd like to respond to this post a bit as well as bring up a few ideas of my own about the demo. First, a brief overview of the demo and its place in Agile.
On all other projects we demo only a few times, but on this project we demo every sprint
So part of Agile is that working software is the best metric for progress. We also favor customer interaction and communication. I view the demo as the ultimate way to realize these things. First, it allows you to show your working software so that people can see what has been done. This is much better than progress reports, lines of code, cyclomatic complexity, and TPS reports (make sure you use the new cover sheet). You're also showing your software to the customer, so you're interacting with them and communicating what you've done. In turn, the customer can tell you how well you're doing in meeting their needs. This way, you can ensure that the project is always on the right track and change what you're doing if the customer changes their mind or (more common) realizes that what they asked for wasn't what they actually needed.
The demo isn't that important though
So the demo is a great way to show your progress and get rapid feedback on it. However, the demo is not an excuse for cutting corners just to be able to show off features. Let's say that you're working on a story and it's about half finished. Let's say the half that's finished is the data access portion of the story and that the UI is not yet complete. You don't care about that though, you want to demo this new feature, so you spend like 20 minutes and create an awful hack that implements a crappy use interface. That way, you have something to show.
That sucks
You've now accrued technical debt (more on this in another post), because instead of having something good that you can build off of, you're going to have to wipe out everything that you've done and start over. Or you're going to base your development off of a hack. Or you just never fix the hack because you don't have time. This makes your application less maintainable and harder to test (if you're hacking together application code, you're probably not going to write tests for it right?) and this will be a future problem. If you just do this in one little place in the application, that's not so bad. But it's a long, slippery slope and it's a dangerous habit to get into. My point is that the demo is not important enough to sacrifice good development practices in order to have a better demo. If you can only get part of a feature working, just show that part. If you need an extra day, push the demo back. Just think of a problem like this with the demo as another change that you need to respond to.
Letting the customer drive the demo is like letting a 16-year old drive a Ferrari
So Jimmy Bogard's idea is to let the customer drive the demo instead of development. He says that in practice he's getting better feedback, the customer is less bored in the demos, and the customer feels that something is really getting delivered. Read his post because I think he has some excellent points.
I'd like to point out, however, that the customer can find ways to crash the app that you never dreamed of. Especially early on in development. They also tend to ask "why" a lot, like "why doesn't that link work" and "why can't I add a customer to a group yet" and so on. In fact, I've found that early on, customers only see the incomplete parts of the features. You know, the ones that you have stories for that you haven't picked up yet. They don't care that you can save a customer and that it works on a distributed system running Oracle and Sql simultaneously accross a 56k WAN, they just see that there's no option for selecting a group for that customer. They're going to complain. They're going to crash things. They're going to make the demo long and painful.
This is just like letting a 16 year old kid drive a ridiculously powerful car; they're going to break it and it's going to be catastrophic because they don't know how to drive it yet. However, if you start them on a Pinto or something, then they'll gradually improve and be able handle a more powerful car (like a Volkswagen) and so on until they're driving a Ferrari without killing themselves.
So don't let the customer drive the demo. Yet.
While there are some great benefits to letting the customer drive the demo, it's a very dangerous thing early on in a project. They're going to break things. They're going to see the faults instead of the features. The feedback you get will probably just make you wonder if you're supposed to salute Captain Obvious indoors. Later in the project, your customer will definitely have things to say and they'll be more familiar with the application. Once that happens, they'll be able to drive effectively, they'll look past the few little things that still aren't working quite right, and they'll learn how to give good feedback during the demo so you'll get some benefits from letting them drive. Just don't rush out there and try this on your next project's first sprint demo because I believe that you're asking for trouble
On all other projects we demo only a few times, but on this project we demo every sprint
So part of Agile is that working software is the best metric for progress. We also favor customer interaction and communication. I view the demo as the ultimate way to realize these things. First, it allows you to show your working software so that people can see what has been done. This is much better than progress reports, lines of code, cyclomatic complexity, and TPS reports (make sure you use the new cover sheet). You're also showing your software to the customer, so you're interacting with them and communicating what you've done. In turn, the customer can tell you how well you're doing in meeting their needs. This way, you can ensure that the project is always on the right track and change what you're doing if the customer changes their mind or (more common) realizes that what they asked for wasn't what they actually needed.
The demo isn't that important though
So the demo is a great way to show your progress and get rapid feedback on it. However, the demo is not an excuse for cutting corners just to be able to show off features. Let's say that you're working on a story and it's about half finished. Let's say the half that's finished is the data access portion of the story and that the UI is not yet complete. You don't care about that though, you want to demo this new feature, so you spend like 20 minutes and create an awful hack that implements a crappy use interface. That way, you have something to show.
That sucks
You've now accrued technical debt (more on this in another post), because instead of having something good that you can build off of, you're going to have to wipe out everything that you've done and start over. Or you're going to base your development off of a hack. Or you just never fix the hack because you don't have time. This makes your application less maintainable and harder to test (if you're hacking together application code, you're probably not going to write tests for it right?) and this will be a future problem. If you just do this in one little place in the application, that's not so bad. But it's a long, slippery slope and it's a dangerous habit to get into. My point is that the demo is not important enough to sacrifice good development practices in order to have a better demo. If you can only get part of a feature working, just show that part. If you need an extra day, push the demo back. Just think of a problem like this with the demo as another change that you need to respond to.
Letting the customer drive the demo is like letting a 16-year old drive a Ferrari
So Jimmy Bogard's idea is to let the customer drive the demo instead of development. He says that in practice he's getting better feedback, the customer is less bored in the demos, and the customer feels that something is really getting delivered. Read his post because I think he has some excellent points.
I'd like to point out, however, that the customer can find ways to crash the app that you never dreamed of. Especially early on in development. They also tend to ask "why" a lot, like "why doesn't that link work" and "why can't I add a customer to a group yet" and so on. In fact, I've found that early on, customers only see the incomplete parts of the features. You know, the ones that you have stories for that you haven't picked up yet. They don't care that you can save a customer and that it works on a distributed system running Oracle and Sql simultaneously accross a 56k WAN, they just see that there's no option for selecting a group for that customer. They're going to complain. They're going to crash things. They're going to make the demo long and painful.
This is just like letting a 16 year old kid drive a ridiculously powerful car; they're going to break it and it's going to be catastrophic because they don't know how to drive it yet. However, if you start them on a Pinto or something, then they'll gradually improve and be able handle a more powerful car (like a Volkswagen) and so on until they're driving a Ferrari without killing themselves.
So don't let the customer drive the demo. Yet.
While there are some great benefits to letting the customer drive the demo, it's a very dangerous thing early on in a project. They're going to break things. They're going to see the faults instead of the features. The feedback you get will probably just make you wonder if you're supposed to salute Captain Obvious indoors. Later in the project, your customer will definitely have things to say and they'll be more familiar with the application. Once that happens, they'll be able to drive effectively, they'll look past the few little things that still aren't working quite right, and they'll learn how to give good feedback during the demo so you'll get some benefits from letting them drive. Just don't rush out there and try this on your next project's first sprint demo because I believe that you're asking for trouble
Wednesday, February 6, 2008
Great article on Agile and management
CIO magazine just published a great article about Agile and management. See if you recognize any names!
Wednesday, January 30, 2008
So, I have a blog now. It's about Agile and stuff. . .
Due to overwhelming demand, I am finally starting my own blog. Or, more accurately, a number of people lately have been complaining about me using the comments section of their blogs to write my own blog. Jeremy Miller also makes a good point about blogging for Software Developers, so here I am.
Whenever I'm giving a technical interview, I almost always ask candidate the question "What does Agile mean to you?" I also point out that if you ask this question to ten different people, you'll probably get ten different answers. I find that this question often tells me a great deal about a person's experience with and understanding of Agile, which is why I ask it. Anyway, to start off my blog, I'm going to give you my answer (Note to interview candidates: If I ask you this, you will not get bonus points for reciting my answer back to me).
To me, Agile is not a process and it's not even really an SDLC; it's an idea. It's a way of thinking about software development, and from this, several processes have come into existence that are built around the idea of Agile such as Scrum, XP, etc. The idea behind Agile starts from the fact that Waterfall (the traditional approach) tends to fail because it is very poor at handling change throughout the project's lifetime and that implementing changes tends to increase the amount of time and work exponentially as the project ages. Agile was designed to take into account that change is inevitable in software, so doing extra work that would need to be re-done when something changes is pointless.
Another idea behind Agile is that non-working software has no value to the company making it. If you can't sell it, people won't use it and you can't make any money from it. Agile addresses this by focusing on delivering working software as rapidly as possible. Ok, so maybe we didn't implement every last little feature, no, but basically we wrote the software. What we write over each iteration, indeed the reason for short iterations, is that we can deliver something that works and has at least some value right away. If the project ends abruptly, hits a deadline, whatever, we may have something that's functional enough to start delivering value to the company and that people may want to use. We can also get rapid feedback on how well the software works.
In contrast, Waterfall is all-or-nothing. You start designing, then you code, then you test, then you release. You get no value until you release, which isn't until the very end. If you fail to get to the very end for any reason, you have nothing that works and therefore a useless block of writing that is your code base and a big pile of money that is no longer yours.
As an aside, I believe that part of the reason that Waterfall fails and Agile succeeds also revolves around why software is hard to write (i.e "Why can't we build software like we build bridges?"). I have an answer to this, but I'll save it for another blog.
Anyway, in order to realize the benefits of Agile, a few basic principles have been thought up that allows these things to occur. They are mostly outlined in the Agile Manifesto (which I highly suggest you read). I am going to attempt to give you an overview of my interpretation of these principles.
We always want working software, so the best metric to measure project by is working software. Lines of code or partial requirement satisfaction is meaningless if those things don't provide something that someone can use.
We favor interacting with people because people are the ones who use the software and whose ideas the software is supposed to implement. You can't ask a document questions. A spec can only say so much. A feature like "User can save their data" means something entirely different to a customer and a developer. Dialog helps to clarify what is needed because by asking questions of each other, people can come to a better understanding of what the customer wants, which is all that really matters anyway (more on that in a later post).
We also favor responsiveness to change because software is all about change. We start to understand the business domain more and more as we work on a product for it. As we understand the business domain better, we start to realize that we made mistakes in implementation (communication helps with this also) so we have to make changes. We also understand that when the customer actually sees the software, sometimes they can say "no, I didn't actually want it to work like that" and we have to rebuild it. This is why we only work on a small chunk of the project at a time and show it to the customer frequently. The more time that elapses between the introduction of a bug and the discovery of it, the harder it is to fix and the more code that might be dependent on the buggy code.
We like to have rapid feedback. We do continuous integration in order to get feedback about if the software works as rapidly as possible. If something breaks, we can fix it right away before it has a chance to corrupt anything else. If someone's code fails to integrate, we can fix it right away because we know about it and it's still easy to fix. If we wait, it becomes harder to fix and harder to integrate.
We are mindful of the whole of the application as we build it, so we know when we must make a decision on when to implement something. We don't build things that we don't know about now. If we build something that we're going to use in the future, it's possible that the requirements will change before the future arrives. We do build things so that we can incorporate new functionality into our code later, but we are using those things now; we'll expand on them later. We build things so that we can change them as the need for change arises, because we know that change is inevitable.
We don't focus on process, but we evaluate our own process continuously. We recognize that our process can always improve and we always find better ways to do what we do. Improving our own process is simply another way of responding to change, and we know that change will always happen.
We also don't ignore things like documentation, process, and tools. They have their place. We know their place. However, when given a choice, we tend to prefer talking to each other and writing working code. We write as much documentation and use whatever tools we need but we realize that these tools exist only to make us more productive in what we already do, not to ensure the success of our project. We do not use OR/M as a crutch because we don't know how to persist our data. We do not use IoC containers because we don't know how to resolve our own dependencies. We do not use a Continuous Integration because we don't know how to keep track of our builds and integrate our software. We use these tools because we know that they make it easier for us to focus on building software. We also use them because we have had to do these things manually before and while we understand how to do them, we recognize that tools can save us time by doing for us what we would otherwise do exactly the same way.
Now, a number of people have created a number of tools, ideas, and methods that help facilitate these things. Processes like Scrum and eXtreme Programming are ways to realize the benefits of Agile, but just because you do them, you are not Agile. There are coding principles such as inversion of control, the single responsibility principle, don't repeat yourself, test driven development, etc, but you aren't being Agile by just blindly following them. You can write enough stories to consume three acres of rainforest's worth of note cards every hour, but that won't make you Agile either. You can have iterations and not be Agile. You can write unit tests and not be Agile. You can do anything you can think of and still not be Agile, because Agile isn't about what you do.
In order to truly BE Agile, you must embrace that Agile is just an idea. It is a way of thinking about development that will help you to deliver a successful software project. There are many interpretations of what exactly that means and many processes that can help you in implementing the idea of being Agile. Ultimately, as long as you are realizing the benefits of being responsive to change and delivering working software that has business value, you are Agile, no matter what you're doing.
Whenever I'm giving a technical interview, I almost always ask candidate the question "What does Agile mean to you?" I also point out that if you ask this question to ten different people, you'll probably get ten different answers. I find that this question often tells me a great deal about a person's experience with and understanding of Agile, which is why I ask it. Anyway, to start off my blog, I'm going to give you my answer (Note to interview candidates: If I ask you this, you will not get bonus points for reciting my answer back to me).
To me, Agile is not a process and it's not even really an SDLC; it's an idea. It's a way of thinking about software development, and from this, several processes have come into existence that are built around the idea of Agile such as Scrum, XP, etc. The idea behind Agile starts from the fact that Waterfall (the traditional approach) tends to fail because it is very poor at handling change throughout the project's lifetime and that implementing changes tends to increase the amount of time and work exponentially as the project ages. Agile was designed to take into account that change is inevitable in software, so doing extra work that would need to be re-done when something changes is pointless.
Another idea behind Agile is that non-working software has no value to the company making it. If you can't sell it, people won't use it and you can't make any money from it. Agile addresses this by focusing on delivering working software as rapidly as possible. Ok, so maybe we didn't implement every last little feature, no, but basically we wrote the software. What we write over each iteration, indeed the reason for short iterations, is that we can deliver something that works and has at least some value right away. If the project ends abruptly, hits a deadline, whatever, we may have something that's functional enough to start delivering value to the company and that people may want to use. We can also get rapid feedback on how well the software works.
In contrast, Waterfall is all-or-nothing. You start designing, then you code, then you test, then you release. You get no value until you release, which isn't until the very end. If you fail to get to the very end for any reason, you have nothing that works and therefore a useless block of writing that is your code base and a big pile of money that is no longer yours.
As an aside, I believe that part of the reason that Waterfall fails and Agile succeeds also revolves around why software is hard to write (i.e "Why can't we build software like we build bridges?"). I have an answer to this, but I'll save it for another blog.
Anyway, in order to realize the benefits of Agile, a few basic principles have been thought up that allows these things to occur. They are mostly outlined in the Agile Manifesto (which I highly suggest you read). I am going to attempt to give you an overview of my interpretation of these principles.
We always want working software, so the best metric to measure project by is working software. Lines of code or partial requirement satisfaction is meaningless if those things don't provide something that someone can use.
We favor interacting with people because people are the ones who use the software and whose ideas the software is supposed to implement. You can't ask a document questions. A spec can only say so much. A feature like "User can save their data" means something entirely different to a customer and a developer. Dialog helps to clarify what is needed because by asking questions of each other, people can come to a better understanding of what the customer wants, which is all that really matters anyway (more on that in a later post).
We also favor responsiveness to change because software is all about change. We start to understand the business domain more and more as we work on a product for it. As we understand the business domain better, we start to realize that we made mistakes in implementation (communication helps with this also) so we have to make changes. We also understand that when the customer actually sees the software, sometimes they can say "no, I didn't actually want it to work like that" and we have to rebuild it. This is why we only work on a small chunk of the project at a time and show it to the customer frequently. The more time that elapses between the introduction of a bug and the discovery of it, the harder it is to fix and the more code that might be dependent on the buggy code.
We like to have rapid feedback. We do continuous integration in order to get feedback about if the software works as rapidly as possible. If something breaks, we can fix it right away before it has a chance to corrupt anything else. If someone's code fails to integrate, we can fix it right away because we know about it and it's still easy to fix. If we wait, it becomes harder to fix and harder to integrate.
We are mindful of the whole of the application as we build it, so we know when we must make a decision on when to implement something. We don't build things that we don't know about now. If we build something that we're going to use in the future, it's possible that the requirements will change before the future arrives. We do build things so that we can incorporate new functionality into our code later, but we are using those things now; we'll expand on them later. We build things so that we can change them as the need for change arises, because we know that change is inevitable.
We don't focus on process, but we evaluate our own process continuously. We recognize that our process can always improve and we always find better ways to do what we do. Improving our own process is simply another way of responding to change, and we know that change will always happen.
We also don't ignore things like documentation, process, and tools. They have their place. We know their place. However, when given a choice, we tend to prefer talking to each other and writing working code. We write as much documentation and use whatever tools we need but we realize that these tools exist only to make us more productive in what we already do, not to ensure the success of our project. We do not use OR/M as a crutch because we don't know how to persist our data. We do not use IoC containers because we don't know how to resolve our own dependencies. We do not use a Continuous Integration because we don't know how to keep track of our builds and integrate our software. We use these tools because we know that they make it easier for us to focus on building software. We also use them because we have had to do these things manually before and while we understand how to do them, we recognize that tools can save us time by doing for us what we would otherwise do exactly the same way.
Now, a number of people have created a number of tools, ideas, and methods that help facilitate these things. Processes like Scrum and eXtreme Programming are ways to realize the benefits of Agile, but just because you do them, you are not Agile. There are coding principles such as inversion of control, the single responsibility principle, don't repeat yourself, test driven development, etc, but you aren't being Agile by just blindly following them. You can write enough stories to consume three acres of rainforest's worth of note cards every hour, but that won't make you Agile either. You can have iterations and not be Agile. You can write unit tests and not be Agile. You can do anything you can think of and still not be Agile, because Agile isn't about what you do.
In order to truly BE Agile, you must embrace that Agile is just an idea. It is a way of thinking about development that will help you to deliver a successful software project. There are many interpretations of what exactly that means and many processes that can help you in implementing the idea of being Agile. Ultimately, as long as you are realizing the benefits of being responsive to change and delivering working software that has business value, you are Agile, no matter what you're doing.
Subscribe to:
Posts (Atom)
