Geeks With Blogs
Jonathan Starr's Blog Thoughts on C#, Ajax, WCF, LINQ, Agile et al.

improve my => 'code' Add to Google

I just read Jeff Atwood's post - Size is the Enemy - and I think his contention that Size => Complexity => Bad Application, is partly true.  But not entirely true.

How does an application become large in the first place?

If an application is successful, and is widely adopted, there is a greater chance that the same application may be reused for more purposes than originally intended.  To handle the new use cases, custom code is added and we get code bloat.  This may be a very successful application from an organization's perspective: the code was originally intended to do X, and now the application is doing triple duty doing X, Y, and Z.

Does SIze => Complexity

From a design perspective, if the same coding patterns are reused throughout a large application, and feature changes are easy to implement, then size of application may not be an issue.  I have seen APL and PERL applications that are far smaller than their C# counterparts, but are far more difficult  for the average developer to maintain.

Do We Have Ways to Manage Large Projects

We have so many tools today to help us analyze large code bases like Reharper, FxCop and Reflector (and many others) that it is possible to argue that size is not the enemy it once was.  It is also easier to write large chunks of code that  help us write data layer, business layer, and even presentation layer code using MyGeneration, DotNetNuke or CodeSmith.

Other technologies that are helping us manage larger projects are (1) unit testing tools so that we can check that code fixes don't have unintended consequences (2) more performant dll linking in .NET that allow for more encpasulation (3) better SCM tools to manage changes to source code, automate builds etc.

Bottom Line

In the final analysis, as processor speeds continue to increase, and storage continues to become less of a bottleneck, we will continue to see larger applications developed and marketed.  I expect more tools will be released to help us manage these larger applications.

In the end, we should not call an application bad because of its sheer size - that may in fact be an indicator of its market success.  But we should criticize applications for being poorly designed, inconsistent, or poorly documented.

Interested in your thoughts,

Jonathan Starr

Posted on Wednesday, December 26, 2007 1:49 PM C# , Critique , Software Design , Personal | Back to top

Comments on this post: Size is Half the Enemy

No comments posted yet.
Your comment:
 (will show your gravatar)

Copyright © Jonathan Starr | Powered by: