Software Factories and the YAGNI factor

Steve posted his concerns over software factories and the YAGNI factor. ("You Ain't Gonna Need It")

My concern with Software Factories is that the output from these procedures are chock full of code that you're not going to need, but are included in the mix because that's how the factory works.  I just went through a project where we used a factory approach where our plumbing was provided for us, but it was overkill for our needs.  And instead of helping us out, it's complexity slowed us down.

The output of the factory was full of YAGNI code, but we couldn't easily separate it out from the code that we actually needed.  So we keep it all in place and hope that we never have to touch it and live with a project that is full of code that we just don't have the time to understand.  Our simple project that should have consisted of 1000 lines of code ballooned to ~15,000.  Ouch!

I've heard similar comments about Typed DataSets vs Business Objects - if you count the lines of code in a typed dataset it far outweighs the equivalent if you were to hand-write an equivalent business entity object.

If I recall the above project Steve mentions correctly, the original intention was to include much of that code as external assemblies, and not as source code at all, right Steve? So to me it hardly counts. And I believe you ended up using some other components, like the OpenNetCF framework too. I'm betting you only used a fraction of that framework's functionality too, so is your distaste based on having more raw code for the compiler to chew through?

Just because we don't use the generated code, does that mean it is smelly?

To some degree I suppose, but it happens everywhere, not just in source code - I will never claim to build a project that uses all of the .NET Framework, or a database that uses all the functionality of SQL Server 2005, or a website that uses all of ASP.NET. When I have used typed Datasets, I have never used all of their functionality either.

So, my question is, do you judge the value of a software factory (in Steve's case, read Code Generation) based on how much it covers your required functionality? and do you reduce its value based on how much unused/unwanted functionality it provides you?

Here is another question, this situation taken to the extreme: if the Tests define the functionality, do you then also test to ensure that the components you are testing DO NOT provide additional functionality? Of course you can never write enough tests to prove that no additional functionality is present. What you must avoid doing, in my opinion, is rely on a component's feature (or indirectly, rely on a component's behaviour that uses another component's feature) without having a corresponding test for that behaviour. Otherwise your tests do not define the complete functionality of your component.

So, if someone uses our component that has untested functionality (due to code gen or the software factory's YAGNI features), and they use that functionality, they should write a test that ensures that behaviour is correct (and be prepared to reproduce that behaviour when the referenced component removes that feature [presumably because Steve thot it was smelly :) ] )

Don't get me wrong, I am not in favour of bloatware, nor adding in features I Ain't Gonna Need. I have stood accused of adding features I think might be useful, I will admit that. And I am much less averse to Frameworks than Steve is, having had more positive project experiences with them than he. Steve, I think you would appreciate Jimmy Nilsson's book "Applying Domain-Driven Design and Patterns" for his approach to ensuring the core domain's knowledge and behaviour is properly represented and testable first and adding in the infrastructure to support it (like persistence and presentation) later (iteratively, I'm sure he would want me to say). I am just finishing it and I have enjoyed it immensely. Jimmy blogs here.

 

2 Comments

  • The YAGNI is there to remind you as a developer to invest time in the features that you need for the current iteration and stop wasting time on features you might need in the feature. Imho if a specific software factory generates several layers for you including code in 5 minutes it does not really violates the YAGNI principle. Also a software factory is not only about creating a project from A-Z at the start of a project, instead in a Software Factory there should be different stages. For example a Software Factory should be able to create a Data Access Layer for you (as far as you need it) with maybe some default classes. Next when you need to create a new Gateway class the software factory should do it for you. A nice example if Microsoft's implementation of Software Factories in the name of Guidance Audomation (GAT+GAX)

  • if the divide between what you use vs. what you get is so large ( 1k vs. 15k LOC), then your factory is made up of core assets that are too corse grained. Of course, that must mean you're including source code in your project, which isn't the real level that a SF is supposed to be used at.

    A software factory should be at a much higher level then simple code generation. It should be made up of core assets and support development by assembly, not just a set of CodeSmith templates that create a ton of .cs files.

    Also, this could have been an exception to his company's original software factory intent. A SF will only be valuable if there are 10's or 100's of the same type of application being produced. If not, you're just creating bloat, like Steve sees.

Comments have been disabled for this content.