Derik Whittaker

100% Agreed.

Pingback from  Reflective Perspective - Chris Alcock  » 2008 » August » 07

Hi,

I half agree with "If I had to go stub a select out for a table, I'd be like WTF. Whoever created this app sucks, they did not even create select procs for me".  If I have to create a stub for a select, I would be like WTF, but its because I don't need it so why stub it!

There is absolutely nothing wrong with auto generated code.  The problem that people have is that the auto code generating tools they have used, in most cases, try to generate too much code and therefore don't cover the exact requirements that you have.  That is why in my belief, DSL tools by microsoft for modelling applications is excellent, you can do as much or as little as you like.  

Next people will be saying don't use XSD.exe or the like!

For Brians comments, interfaces are just for testing and they are add too many moving parts? in fact interfaces are a very static part of the application, they define an explicit contract the the consumer of the interface must adhere to and the implementation must directly follow.  And for this reason they are good for testing because there is an expectation in the test and the implementation.

Paul.

1) 'recreating massive amounts of code is expensive and time consuming.' - HUH?  if your code generation is done right, it is worst case one button click, and best case automated as part of your build or whatever and people don't even have to think about it.  I've had projects with tens of thousands of lines of generated code that were trivial to maintain (just a few templates need maintenance).  Even our unit tests for CRUD were generated (this was surprisingly useful).

2) I actually agree with the basic principle behind your 2nd response, however in a data driven design it is pretty rare for for all CRUD operations not to be needed for data that you've determined is required.  The most common exception would be Updates and Deletes.  But because humans aren't writing that code, I don't think there is any actual waste there.  The work you're doing is with the templates.  In fact, a system where you have to specify which operations are required for a specific data table seems like it would involve EXTRA work that serves no other purpose than to conform with the principle, not because you would actually be deferring any real work.  I think a more common problem with the YAGNI principle in data driven design is that people are creating data structures/tables/fields much before they're actually needed by the application.

Not that code generated ORM systems are the best option (I prefer dynamic, runtime generated systems like Linq to SQL), but YAGNI doesn't seem to be a valid excuse for not using them.

>>I actually agree with the basic principle behind your 2nd response, however in a data driven design it is pretty rare for for all CRUD operations not to be needed for data that you've determined is required

Well said.  We're not talking about creating "massive" amounts of CRUD methods.  Maybe only 5-10 per class.  That's not huge and you'll most likely end up creating them anyways for most objects.  So it's not waste at that point if you're only stubbing out just a small select few basic CRUD operations that take in a basic ID, or whatever.

You've been kicked (a good thing) - Trackback from DotNetKicks.com

"Also not mention everyone on the team may not necessarily know/understand how to do the CodeGen"

You're kidding, right?  As opposed to using DI/IoC, which is so much simpler than CodeGen?

One issue with "unused" code (code that isn't used right away; but is available to use a later date) is that despite being unit tested (or not) its use in-the-wild won't be close to when it is written.  This means bug-fixes will be more expensive than necessary.

Go where?

Substitute 'NHibernate' for DI/IoC.  Heck, substitute just about anything.

CodeGen is easy.  I think sometimes people are against it when they don't control it (think the code gen'd by a typed dataset).  If you use something like CodeSmith and control the templates that gen the code, CodeGen can also be awesome.

@Brain:  So, you think writing code that is continually testable is over designing and a waste?

There you go, now you understand.

Let me go turn the faucet on.

>>One issue with "unused" code (code that isn't used right away; but is available to use a later date) is that despite being unit tested (or not) its use in-the-wild won't be close to when it is written.  This means bug-fixes will be more expensive than necessary.

Ok, Lets put this into perspective.  We are not creating needless crud methods.  Don't you agree that most crud methods are going to

a) Accept an incoming Object or ID in order to update or insert a new record to your DB?  Is creating a CRUD method waste in this case that simply accepts the most commonly used parameters you see in pretty much all applications generic enough regardless of the "business requirements now or later".

Lets face it, you're gonna need them and usually you're passing in an ID or object.  Plain and simple.  Why wouldn't you stub out 2 crud methods for that.  Waste?  I don't see how that is waste.  They're pretty generic meaning it's not like you are expecting an ID, CreateDate, or some other specific domain fields here.  It's something that is and will be reused probably 99% of the time.  Then you can create your domain specific methods outside the initial Basic CRUD methods you genereted

Big deal, so maybe you don't use 3 out of your 10 methods that you created for your initial base CRUDs.  Big frigging deal.  Wow, so you multiply 3 x lets say 20 database tables (custom object per table).  Wow I have 60 methods that are waste.  But they all have the same design pattern, same type of signature (they expect and ID or object).  Ok so if you want to unit test them, fine.   But your unit tests will also be pretty much the same minus a few tweaks for those initial CRUD methods you subbed out.  Big deal!  And we know not to add custom methods inside your code-gened methods so your unit tests for those generated CRUDs aren't gonna change much in the future either.

So your argument about waste and maintenance is so minor.  It's not even a huge deal if you even have any waste to begin with and if you are smart when you stub out your CRUD methods to be methods that usually you see in almost every application's DL, then it's not waste.  It's using the Code Generation smartly.  Again, you're only created commonly found CRUDs before your domain specific methods (the methods you create maybe in your own partial class off the main generated class).  What's wrong with a hybrid approach.  Domain specific custom methods and database driven CRUDs that you don't touch but use 99% of the time.

I think this argument goes way too etreme on your side.  There is waste but then this is kinda ridiculous.  What waste have we made when having to create CRUDs on every table in the database.  That's a waste of TIME.

BTW, I just noticed this.  Next to this post is the 'our sponsors' box (well, next to all posts), and one of them is Iron Speed Designer.

A code-gen tool.

Just thought that was funny.

@Paul - I never said interfaces are just for testing.  Interfacing are for exactly what you said they are - what I said was putting in interfaces, just for testing, is adding extra moving parts.

If you need them in your application, you need them - if you're putting it in just for your testing framework then you're adding extra moving parts.

>>>think the code gen'd by a typed dataset

oh man, don't get me into that because right now I am forced to use typed Datasets at my new place.  That's lousy code-gen by Microsoft because you have to deal the the management of not only a designer file but all that comes with it.  Sure added "convenience" but at a huge cost (non-flexible architecture, hard to create a BL off this sh** and so fourth).  

Then you have to deal with the damn data adapter and then that with it's internal table relationships in a large object all because you want convenience...not very smart architecture design.  Then you have to deal with all the issues that arise with a typed dataset, work arounds, etc. for what you could do better or at least easier meaning flexibility with custom objects.  The work to set that up is more but you have a lot less crap and more important true separation of concerns and ability to create the layers you want in an application for future growth because you have that separation.

Then there are the "hokie issues" with offline data stores and this typed dataset crap...old school way to use ASP.NET where you have to tightly couple your damn DL with typed datasets straight to your PL...you can just think of how weak your architecture and rigid that is.   So that's a very bad example of code gen but you proved a point.  That Microsoft code gens stuff so code gen is not all that bad right?  

Isn't that the point here?   If Code Gen was so bad, then why would Microsoft ever do that?

We use a self build codegen witch generates a complete ASP.NET application based on UML class model's instead of the database. This way we can start projects with the model in mind and not the DB. The DB is created through hbm2ddl. Through this we have a solid base for the application and can focus on behaviour instead of plumbing and simple CRUD. The unit tests for the generated code are also generated. I'm not really sure why people are so reluctant to codegen maybe if it's generated they don't trust it or it's the 'It's not build by me' syndrom. Whatever we are happy with. Look for a good experience with.

The problem with CodeGen isn't just the "waste" aspect (which can be a significant amount.  If you've had to maintain large applications with dramatically shifting requirements over the period of a few years you experience this pain point), but the forced architecture.

Code-gen tools/templates make an assumption (Very big assumption) of how you want to build your software.  Not all domains need 3 tiers.  Some domains need parallel 5 tiered pipelines, etc.  Perhaps you're going with a strict DTO/Value Object interface between each tier...  You get the point.

And datasets aren't codegen.  They're an abomination born by the devil himself.  Just try changing your DB schema or the dataset schema and feel the tendrils of pure evil wrap around your soul.

As a small ISV I love code-gen, it prevents expressing myself twice, three times and four time.

I agree it is ugly, but there is no way that I'm writting my DDL for Oracle & SQL Server, My Hibernate Mappings, my DataObjects, I feel my time is at waste here.

As for un-used methods as an ISV we often write functions that no-one uses, why people by the software because it has this bell or whistle but never use it.

I agree with your comments to some extent but please, religion with-in moderation my friend.

Pingback from  Link Post Sunday 08/10 | Mr Sun Studios

<i>re-creating massive amounts of code is expensive and time consuming</i>

Umm... no. If codegen is expensive or time-consuming, you're doing it wrong. If members of the team have a difficult time using code, you're doing something wrong.

You're simply attributing the problems to the wrong source. Godegen is clearly not the issue here. The issue is implementation and training.

So you come up with this as a substitute:

<i>Code you create now, but do not have a direct, immediate need for NOW is waste.</i>

But the NOW timeline is really short-sighted.

Here's a classic. We've rigged our generated entity code to have special handling on any columns named "CreatedDate" and "ModifiedDate".  Of course, lots of the primary entity tables we created simply didn't have these columns.

Now, to start with, we don't have a reporting interface or any business logic associated with these columns, so according to your logic adding these columns (i.e.: adding code) is a waste.  And of course, that continues to be true until a problem arises that is solved by having these columns (except that they don't exist).  I can't now go back and add these columns and suddenly get the data, but hey at least I didn't waste any time, right?

The problem with only handling immediate needs is that it opens the door to ignoring common failures.

Take my example. I know from experience that having these columns on specific tables <b>will</b> be useful. Maybe not now, but definitely soon. And we're not talking about full table-auditing, just a couple columns. We can get that information for a time usage so small that it's basically free and you're telling me that it's a waste because we're not going to use those columns now?

As always, good judgment and experience must be applied when making decisions about what code and features to build. I've spent a lot of time "paying for" mistakes that were wrought from the "we don't need it now" mentality.

In the case of our two dates (Created and Modified), we had to fight through support issues that relied on the non-existent data. A year ago, our product didn't have a support team, so nobody put them in, we didn't need them NOW.  That cost us time and money for what should've been a "free" feature.

Turns out we'll likely need a full change history on a couple of the tables.. That's fine, we can't get that "for free", so it's OK that we didn't "waste time".

And what about features that don't get used? If I build 5 features and only 1 gets used, is that waste? Technically it is, but realistically, not every feature is going to be a hit. In fact, it's generally acknowledged that failures are a very important component of success. Maybe it just takes the implementation of 5 features to find one that "sticks", all of that "unused code" may be a "success" in some people's book.

I think you can get my point here, waste is not as simple as defining code that does or does not get used. You also have to factor opportunity costs for the code that is written and the "timing of the time". Hours are not equal, the hour when your datacenter is down has a very different value than the hour I spent writing this post.

Calling unused code the "Worst of the wastes" is difficult to swallow without a little deeper comparative analysis. But given the difficulty of even analyzing the value of unused code, I think you'd be in for a challenge there.

>>>I agree it is ugly

Why?  I think that depends on how you code gened it and what tool you used.  The code that architects I have worked with code genened some of the cleanest (simplest patterns) code that works and is simple across the board with little waste and I can prove it by telling you that most methods we have used in every class that was code gened.

>>>Code-gen tools/templates make an assumption (Very big assumption) of how you want to build your software.  Not all domains need 3 tiers.  Some domains need parallel 5 tiered pipelines, etc.  Perhaps you're going with a strict DTO/Value Object interface between each tier...  You get the point.

What is prohibiting you from stubbing out additional layers if you use Code Smith for example.  I don't agree or see your argument.

>>>>And datasets aren't codegen.  They're an abomination born by the devil himself.  Just try changing your DB schema or the dataset schema and feel the tendrils of pure evil wrap around your soul.

That one cracked me up.  Totally agreed.  DataSets are pure hogs and there is a lot of shit in them to manage.

Although, in the interest of fairness, I will point out that while fixing a bug, I just deleted 10 lines of code, only because they weren't used anywhere.

What's more of a waste.  Deleting 10 lines of code or having to take time to stub them out.

In this particular case, the 10 lines of code were originally typed because we thought they would be needed.  Minor change of requirements later, turns out they weren't, so when I came across them again (even later), I nuked them.

Pingback from  Predict the Future For Me | Ekinoderm