Occasionally in some discussions on Agile the topic of Nightly Builds comes up, and while I will agree that its something that should be done during a sprint, and while its mentioned in a couple of newer editions on the methodology I just see it as something that needs to be done. You don't need to be on a Scrum Team or on an Agile Sprint to see the value in a nightly build, if your code is building every night then it means people are doing their work and verifying that things work properly, nothing more special than that. Methodologies are great to build a framework around, and often give high level management some way to say they are doing something that is hot and on topic, or allow them to utilize yet another buzzword. Outside of that nightly builds are good for everyone.
The gains are immense, not only knowing that any day someone can check out the source tree and get the code to build in their environment but once you have taken the step of having a build happen then you can go onto the next step of automated testing. Whether its a suite of Unit Tests or an automated Smoke Test, unless code is building you are not taking that next step, adding those steps allows one to have a good deal of confidence against the code checked in. Having tests run every night allows you to know that your code is good in the source tree not only because it builds but that its passing a set of tests deemed necessary for the code to always pass. Confidence assured.
Of course if you don't have the coding to back this up, say check ins are only occurring every couple of days then this won't work for you. In larger, or mature, products you have code being checked in all the time, and that's where the gain is. You need to determine the best output for your team.
So before worrying about whether or not you are following a specific methodology get some basics in place first, Nightly Builds is one of the most important.
Monday, May 19, 2008
Monday, May 5, 2008
Software is NOT Manufacturing
I've seen it alot whenever discussions on methodologies come up, especially the ISO and CMMI ones, but it usually comes down to the whole mechanism of why software is different than making widgets. Thinking about this off and on, I came to the conclusion for myself, that there are some major differences here and it all comes down to the fact that widgets ARE different than software. Beyond the physical there are some major differences between generating a product that people use, utilize or somehow adapt to their life and software which can also have the same implications is very different. I came up with what I consider 3 major points, makes it easy because no one really has a top 3 and a half reasons list, in which they are very different and thats design, implementation and release. Yes, they are similar but that's about where it all ends to me. So let's take something amorphous called "software" or "the programme" and compare it to "Plastic Shovel Red No.2".
Mind you this is all my opinion, if you feel different go ahead and comment or stop reading now.
Design. When you create software there are lots of meetings and specifications and documents that tell you how it is going to be and what it is going to be, unless its a personal or open source project (or even Agile!) where this may change. Input is gathered, perhaps some market research, after all you want to know what it is you are building before you go ahead and do it. Someone has to know before starting to even think about it that the particular software is going to be useful, or will be, in some niche that will create an entry point for its particular functionality - if its not going to be useful no one will want it or probably not want to work on it either. So that need is part of the design and helps shape what the software will be, there is an idea and a goal to reach then, so the work on the design and any associated research is all about what will help the software become that need. Now the Plastic Shovel is fairly simple, it has some uses (more if you consider the imagination of the typical 4 year old) that are known ahead of time and a shape that needs to be made. It's considered from multiple angles and multiple measurements (how long should it be? how wide? how thick? when we make the handle should it have an O shape at the top or another shape?) all of this is considered at the beginning. Once run through a couple of times, perhaps a meeting or two just as might be had for the programme, a decision is made that this is the way we want it. A prototype is made, for either one, and that is then presented and demo'ed to someone or a group and input is solicited. Now this is the important part. Once that input is given software can go through more rounds of feedback and use while Plastic Shovel is decided upon and then you know what....decision made and go make it!
This is what I call the Feedback Divergence. For software you can continually elcit feedback, because its complex and evolves, almost as if its a living thing made of many living things and what you end up with is often not what you started with. A plastic shovel, on the other hand, once decided upon has its specs sent to the factory floor with orders to make X numbers of them, software basically has one thing made - the source code. Sure someone can come back and say that Plastic Shovel was horrible and broke when too much sand was put on it, but that just means we start the process again with Plastic Shovel and make a completely different version of it for the factory to press out later. That feedback does not go back into the design and create a different one, because its already been made! Software, because it can be built at any point of the process can elicit input at any time and be made different at that time.
Implementation. Part of putting the design down on the factory floor for the Plastic Shovel is that a mold is made, and machines are set for creating thousands of cheap Plastic Shovel Red No.2. Once that is done the Shovel is committed (now I know that's an Agile term but its also true) the Shovel will now be made by the thousands. It's now being implemented by the workers on the floor whose only job at this point is to make thousands of nice, bright plastic shovels in Red No.2. Not Red No.3 because little Suzie wants that color to go with her polka dotted suit, or Green No.5 because Jimmy thinks its cool, its all Red No.2. If you want another color you are buying another product because once that shovel is stamped out on the factory floor its done, been implemented as designed and is not going to be personalized at the factory at all. Not in the plan. Software can do that, because its able to be adjusted because its not a physical object.
This is what I call the Hand Divergence. If I can hold it in my hand there are a limited number of mechanisms by which this object can be adjusted, personalized and or changed. With a significantly smaller number of those changes actually provided by the manufacturer. Once its done its done. Software in some essences is never done, because you are making a new version off an old set of source and code which together comprises the whole, and because its malleable you can infinitely change it. You can't do that with a plastic shovel, at some point you will come to an end of possibilities to change it, software does not work that way.
Release. When software is "done" by a project sense its given to the Customer, perhaps on a CD or a download, and there is probably a release party somewhere with beer, food and hula girls. Well not everyone gets the hula girls, heck some people don't even get the beer. The point is, you can take your checklist and look at it versus your software and say you have X% functionality done, which will be acceptable to the Customer at this time, with other improvements in queue, or soon to be in queue once they install the programme and use it. But is it really done? Not at all. You've hit a milestone where you can say that the functionality that was originally designed for was satisfied to a degree, the closer to 100% you get the better off your project was managed. Now that plastic shovel, once its off the factory floor its either on its way to some discount retailer near you to get a price tag, or its going to be bundled with the "Super Special Summer Sand Spectacular" where it takes its place in a bucket with a bunch of other cheaply made plastic items that are all COMPLETE!
I have no divergence with this one, unless you want to call it the Profit Divergence. Part of what makes the Plastic Shovel Red No.2 special is that once it was sent to the factory floor we knew exactly how many needed to be made and sold to generate a profit for the company. For software we are either paid for the work up front, where we probably went over budget because of circumstances beyond our control, or it will be sold and people will go out and driver desire for the programme so we can continually make money off it and get people in line for the improvements that come later. At this point the story for Plastic Shovel Red No.2 is done, it may go back for a redesign but maybe not, software is just beginning and still has a long road ahead.
So there you go, my rationale as to why software is not manufacturing.
Mind you this is all my opinion, if you feel different go ahead and comment or stop reading now.
Design. When you create software there are lots of meetings and specifications and documents that tell you how it is going to be and what it is going to be, unless its a personal or open source project (or even Agile!) where this may change. Input is gathered, perhaps some market research, after all you want to know what it is you are building before you go ahead and do it. Someone has to know before starting to even think about it that the particular software is going to be useful, or will be, in some niche that will create an entry point for its particular functionality - if its not going to be useful no one will want it or probably not want to work on it either. So that need is part of the design and helps shape what the software will be, there is an idea and a goal to reach then, so the work on the design and any associated research is all about what will help the software become that need. Now the Plastic Shovel is fairly simple, it has some uses (more if you consider the imagination of the typical 4 year old) that are known ahead of time and a shape that needs to be made. It's considered from multiple angles and multiple measurements (how long should it be? how wide? how thick? when we make the handle should it have an O shape at the top or another shape?) all of this is considered at the beginning. Once run through a couple of times, perhaps a meeting or two just as might be had for the programme, a decision is made that this is the way we want it. A prototype is made, for either one, and that is then presented and demo'ed to someone or a group and input is solicited. Now this is the important part. Once that input is given software can go through more rounds of feedback and use while Plastic Shovel is decided upon and then you know what....decision made and go make it!
This is what I call the Feedback Divergence. For software you can continually elcit feedback, because its complex and evolves, almost as if its a living thing made of many living things and what you end up with is often not what you started with. A plastic shovel, on the other hand, once decided upon has its specs sent to the factory floor with orders to make X numbers of them, software basically has one thing made - the source code. Sure someone can come back and say that Plastic Shovel was horrible and broke when too much sand was put on it, but that just means we start the process again with Plastic Shovel and make a completely different version of it for the factory to press out later. That feedback does not go back into the design and create a different one, because its already been made! Software, because it can be built at any point of the process can elicit input at any time and be made different at that time.
Implementation. Part of putting the design down on the factory floor for the Plastic Shovel is that a mold is made, and machines are set for creating thousands of cheap Plastic Shovel Red No.2. Once that is done the Shovel is committed (now I know that's an Agile term but its also true) the Shovel will now be made by the thousands. It's now being implemented by the workers on the floor whose only job at this point is to make thousands of nice, bright plastic shovels in Red No.2. Not Red No.3 because little Suzie wants that color to go with her polka dotted suit, or Green No.5 because Jimmy thinks its cool, its all Red No.2. If you want another color you are buying another product because once that shovel is stamped out on the factory floor its done, been implemented as designed and is not going to be personalized at the factory at all. Not in the plan. Software can do that, because its able to be adjusted because its not a physical object.
This is what I call the Hand Divergence. If I can hold it in my hand there are a limited number of mechanisms by which this object can be adjusted, personalized and or changed. With a significantly smaller number of those changes actually provided by the manufacturer. Once its done its done. Software in some essences is never done, because you are making a new version off an old set of source and code which together comprises the whole, and because its malleable you can infinitely change it. You can't do that with a plastic shovel, at some point you will come to an end of possibilities to change it, software does not work that way.
Release. When software is "done" by a project sense its given to the Customer, perhaps on a CD or a download, and there is probably a release party somewhere with beer, food and hula girls. Well not everyone gets the hula girls, heck some people don't even get the beer. The point is, you can take your checklist and look at it versus your software and say you have X% functionality done, which will be acceptable to the Customer at this time, with other improvements in queue, or soon to be in queue once they install the programme and use it. But is it really done? Not at all. You've hit a milestone where you can say that the functionality that was originally designed for was satisfied to a degree, the closer to 100% you get the better off your project was managed. Now that plastic shovel, once its off the factory floor its either on its way to some discount retailer near you to get a price tag, or its going to be bundled with the "Super Special Summer Sand Spectacular" where it takes its place in a bucket with a bunch of other cheaply made plastic items that are all COMPLETE!
I have no divergence with this one, unless you want to call it the Profit Divergence. Part of what makes the Plastic Shovel Red No.2 special is that once it was sent to the factory floor we knew exactly how many needed to be made and sold to generate a profit for the company. For software we are either paid for the work up front, where we probably went over budget because of circumstances beyond our control, or it will be sold and people will go out and driver desire for the programme so we can continually make money off it and get people in line for the improvements that come later. At this point the story for Plastic Shovel Red No.2 is done, it may go back for a redesign but maybe not, software is just beginning and still has a long road ahead.
So there you go, my rationale as to why software is not manufacturing.
Subscribe to:
Posts (Atom)