Open Source Projects & Code Generation Tools
I am constantly being approach by members of management and other team members to consider using Open Source Projects & Code Generation tools to reduce our development effort.
When I say Open Source projects I am not referring to open source tools like Nant, FxCop, WebServiceStudio, Nunit, Fitnesse, BugTracker.NET, Reflector, Ndoc, Paint.NET, or any other tools like these. I am talking about CSLA.NET, .NET Pet Shop, .net Tiers, DotNetNuke, and open source projects that are meant to provide you with plug-in parts of your architecture that are code ready, and advertise only small code tweaks are needed.
I am not opposed to using Open Source Projects & Code Generation tools as long as they do not create more work in other areas than they promise to accomplish in the areas they reduce work in. I am a firm believer in reusing assets that are available. I do not believe "it must be built here to be used". But I have seen to many people look at Open Source Projects & Code Generation tools as shortcuts. Shortcuts are something I am always opposed to. Shortcuts to me equal either laziness, or a shortsighted budget focus. It usually indicates the person can not see the big picture, they only see the small one right in front of them.
In lower ceremony projects they usually can offer some advantages. But that is only if they benefit the entire process. That means that they are also capable of handling updates, handle maintenance, handle customization, handle testing, and handle all these things gracefully. Most of what I have had the experience to see, did not handle any of these things gracefully. They also must have a low learning curve. I have seen teams spend more time learning how to use these types of tools than it would have taken them to design it, document it, and code it themselves.
For prototypes I think they work great, if you already know how to use them. Just like all the wizards in Visual Studio we use to slap together something for demonstration purposes. But the mess the wizards and generation tools make are usually not production level code.
For Product Line Engineering the Open Source Projects & Code Generation tools must also provide the assets that are critical to PLE projects. That includes detailed documentation on their design, their architecture, performance metrics, tests, and any other details provided by a good COTS candidate. These assets then must be re-worked to fit into your process. Getting these tools into a PLE process is usually more work than it is worth. You also have to consider the fact that the part of your PLE architecture you plan to use these on, are now dependent on them, as with any other COTS product. So you better be sure they are well established.
In all situations the Open Source Projects & Code Generation has to be a good fit for your architecture. I have seen teams spend tons of time tweaking the projects and code to make them semi-fit there architecture, just so they could say they successfully pulled off their idea of using the Open Source Projects & Code Generation tools. When in reality it was a flop when you consider the amount of time they spent on getting to the point they could say it worked. And when this happens they have usually damaged the architecture.
I am not totally opposed to using Open Source Projects & Code Generation tools, and I can see they have come a long way. You should always include a lot of research time upfront to make sure you are getting a good fit for your project if you are considering going this route.
You have to make sure you are not making your architecture fit the Open Source Projects & Code Generation tools. In my book they either are a good fit all around or they are not. The benefits must outweigh the costs. Keeping in mind saving development time is not the only benefit. This is a very shortsighted view of their benefits and will usually get you in trouble. Just saving development time is not a good enough reason. You have to consider the overall process, every phase. I have seen the Open Source Projects & Code Generation Tools really burn a lot of maintenance phases, testing phases, and completely trash subsequent releases.
Open Source Projects & Code Generation tools always need a higher degree of management and constraints around their use. If this doesn't happen, then they usually only cause headaches.
The one I have used and will continue to use as long as the quality remains the same is the Enterprise Library from Microsoft. They provide sample, great documentation, and tests.
When I say Open Source projects I am not referring to open source tools like Nant, FxCop, WebServiceStudio, Nunit, Fitnesse, BugTracker.NET, Reflector, Ndoc, Paint.NET, or any other tools like these. I am talking about CSLA.NET, .NET Pet Shop, .net Tiers, DotNetNuke, and open source projects that are meant to provide you with plug-in parts of your architecture that are code ready, and advertise only small code tweaks are needed.
I am not opposed to using Open Source Projects & Code Generation tools as long as they do not create more work in other areas than they promise to accomplish in the areas they reduce work in. I am a firm believer in reusing assets that are available. I do not believe "it must be built here to be used". But I have seen to many people look at Open Source Projects & Code Generation tools as shortcuts. Shortcuts are something I am always opposed to. Shortcuts to me equal either laziness, or a shortsighted budget focus. It usually indicates the person can not see the big picture, they only see the small one right in front of them.
In lower ceremony projects they usually can offer some advantages. But that is only if they benefit the entire process. That means that they are also capable of handling updates, handle maintenance, handle customization, handle testing, and handle all these things gracefully. Most of what I have had the experience to see, did not handle any of these things gracefully. They also must have a low learning curve. I have seen teams spend more time learning how to use these types of tools than it would have taken them to design it, document it, and code it themselves.
For prototypes I think they work great, if you already know how to use them. Just like all the wizards in Visual Studio we use to slap together something for demonstration purposes. But the mess the wizards and generation tools make are usually not production level code.
For Product Line Engineering the Open Source Projects & Code Generation tools must also provide the assets that are critical to PLE projects. That includes detailed documentation on their design, their architecture, performance metrics, tests, and any other details provided by a good COTS candidate. These assets then must be re-worked to fit into your process. Getting these tools into a PLE process is usually more work than it is worth. You also have to consider the fact that the part of your PLE architecture you plan to use these on, are now dependent on them, as with any other COTS product. So you better be sure they are well established.
In all situations the Open Source Projects & Code Generation has to be a good fit for your architecture. I have seen teams spend tons of time tweaking the projects and code to make them semi-fit there architecture, just so they could say they successfully pulled off their idea of using the Open Source Projects & Code Generation tools. When in reality it was a flop when you consider the amount of time they spent on getting to the point they could say it worked. And when this happens they have usually damaged the architecture.
I am not totally opposed to using Open Source Projects & Code Generation tools, and I can see they have come a long way. You should always include a lot of research time upfront to make sure you are getting a good fit for your project if you are considering going this route.
You have to make sure you are not making your architecture fit the Open Source Projects & Code Generation tools. In my book they either are a good fit all around or they are not. The benefits must outweigh the costs. Keeping in mind saving development time is not the only benefit. This is a very shortsighted view of their benefits and will usually get you in trouble. Just saving development time is not a good enough reason. You have to consider the overall process, every phase. I have seen the Open Source Projects & Code Generation Tools really burn a lot of maintenance phases, testing phases, and completely trash subsequent releases.
Open Source Projects & Code Generation tools always need a higher degree of management and constraints around their use. If this doesn't happen, then they usually only cause headaches.
The one I have used and will continue to use as long as the quality remains the same is the Enterprise Library from Microsoft. They provide sample, great documentation, and tests.
0 Comments:
Post a Comment
<< Home