Introducing code generators in a project. Could this be a risk?

Question

I have made a code review for a .NET project (VS2008/.NET 3.5). I noticed that many business entitities and data access components were created from scratch while not having a business demand for implementing complex rocket-science code.

Many review-issues were related to the data access layer.

Looking at the architecture that is used I recommended to introduce a code generator like CodeSmith in combination with .NetTiers.

The tech lead liked the idea but he said that introducing this would be risky because the team is in the middle of the development stage and the project is too small.

Is it preferable to introduce a codegen at this stage ?

(this topic is not about which code gen tool must be used, but more about timing when to introduce it or about introducing it or not)

Answer 1

You might look at T4 to generate code, built into Visual Studio, no extra installation.

I've read some very useful tutorials by Oleg and it would be easy to start to apply to one part of your development at a time, mitigating the risk involved. Then if proving it's worth, apply it more.

Answer 2

There's always a risk when adding new stuff to a project in the middle, especially when the new stuff is replacing old stuff. Basically any code that depended on the old code needs to be tested completely. This is part of the risk and cost of changing.

The risk comes with bugs. Assuming that everything works correctly, then it isn't a problem. But what happens when there's a problem? Then the cost goes up because extra time is needed to go through the debug/test cycle again.

The only time this would make sense in the middle is if you haven't done any of the testing yet. However, if that were the case, then I would be more worried about the overall quality in general because I would prefer such a low-level layer would have been thoroughly tested throughout the process.

Answer 3

• Leave alone the existing, hand-written code that works, at least for now
• If you can find a code generator that really makes it easier/quicker to develop new components, then I don't see how it could pose a risk or be hard to "sell" to the developers
• While it's better to generate repetitive code than to write it manually, it's really just a band-aid
• Ideally you should find a way to extract the repetitive aspects in a way that allows you to manually write non-repetetive code.
• E.g. use NHibernate for data access so that you don't have to write CRUD operations for each domain object and instead just specify how they're mapped to DB tables.

Answer 4

I would be very careful at introducing a code generator in a team like that. Particularly the ones you mentioned. That said, this can vary with the project/team.

Consider:

• Is the current hand-written dal enough for the real requirements of the project? This is particularly important if you have a real need to introduce paging and other similar features. If the team doesn't have these in place and is already facing issues, odds are they will have a hard time moving forward. I would say this is more a case for an ORM, specially something lite.
• Does part of the team have any previous knowledge on one of these tools? Have those members used them on a successful project? This is more important than it might appear, specially if you are considering something as broad as nettiers, which introduces its own issues/mind set. Consider something easy to understand, and that doesn't takes you to an all out change.
• Do you have a clear understanding on how the tool and the way it is going to be used affect the developers time to introduce changes. Whichever the tool, avoid having it put a date/time on the files, as it gets in the middle of knowing what have changed when looking at the source control log. Whichever the tool you use, the developers should be able to work with it with no hassles, if not it will get in the middle (specially on an ongoing project).
• How will you integrate the generated with the already non generated code? If this is not clear, you might be talking about a full throw away. If you are in that scenario, introducing a new tool is not likely to solve the team issues.
• You have no test automation in place. Doing changes with no test automation is a lot harder, specially because it is hard not to break something.

Ps. we introduced nettiers in a couple of projects sometime ago (seemed nice to us :(). We did so at the beginning of the project, and even then it really got in the middle. Granted we had more code faster, but that really didn't mean we had more code that mattered. New features started being developed with custom code (plus linq2sql), productivity and quality went up fast. We have never used it again and never missed it. We use ORMs extensively, and other more focused code gen here and there.

Answer 5

I've worked on a couple of projects with code generators (not counting standard tools like Visual C++ etc..). In the beginning they are cool. Real time-savers. In the end, practically everyone hates them. They require too much tailoring or too many work arounds for any new functionality that you add later. Also, some poor schlub usually ends up being stuck on the project forever because they are the only one who knows how to modify the tool. You probably don't want that guy to be you:)

Like Michael suggested, the correct route is to find a way to eliminate the repetitive coding through a redesign.