Chris Donnan : Programming - Brooklyn Style

Slice the Work Vertically, Not Horizontally

The metaphor of software development as construction is common, but horribly wrong. Approaching software development as constructing a structure on top of a foundation, then adding the finishing trim can be a slow, painful path to project failure.

Time and time again I’ve learned or observed that projects go much smoother when you build vertically instead of horizontally. What I mean by this is that you build a new system by creating a feature at a time with the entire stack of UI, business logic, and database work to make the feature fully functional. As you build new features you religiously eliminate duplication to avoid creating a Stovepipe anti-pattern and harvest reusable code.

One of the more disappointing project failures I’ve observed was the very first .Net pilot project in a VB6 shop. I wasn’t involved with the project, but I had a stake in the project as it was going to prove the viability of .Net for application development and also be a pilot for doing iterative development.* Unfortunately they blundered by crafting an iteration plan that called for them to write the entire data access layer first, the business layer second, then finally put together the user interface. It failed miserably. When the project was cancelled midway they didn’t have the slightest bit of deployable code because they had focused solely on the backend database. One of the other things they found out was that the data access they coded wasn’t exactly what the business and UI layers needed. In other words, they had wasted effort by speculatively creating code that turned out to be unnecessary.

He hit the nail on the head. YOU NEED TO HAVE DEPLOYABLE CODE ALL THE TIME. The risk of waterfalling is all or nothing. Either you finish the building, or you do not. I was just happy to see someone else using my terms exactly “Slice the Work Vertically, Not Horizontally” to describe how to do development work!!! The whole article is actually great - I suggest the full read.

He also references in this blog entry one of my favorite papers http://www.objectmentor.com/resources/articles/Principles_and_Patterns.PDF . Read it if you have not

He also references using IoC/DI frameworks. Please - dev community - get behind IoC/DI frameworks and ideas. Seperation of implementation and abstraction is KEY and these IoC/DI tools REALLY help make this stuff a help you!

All in all - he touched on a few near and dear to my heart items. I just had to give my 10 penny commentary

-CD

Other references to people waging this war:

Objects vs. DataSets - Is it Really About the Technical Aspects?

excerpt:
I find that that the most interesting reasons for choosing Objects vs. DataSets are less technical, but more about the project, the developer’s methodology, and the developer’s preference. The technical reasons for choosing one over the other are pretty weak and can be resolved pretty easily.

My 2 Cents :
I guess I can acept this. I do believe that in a quick and dirty situation - datasets win. Maybe some would argue that the level of developer would favor the dataset solution - the custom object solution REALLY seems simpler to me - I guess I am just biased.

Displaying aggregates: DataSet vs. Domain object performance

excerpt:
…. I work with someone who coded a bunch of stuff using a dataset. unfortunatly, due to the complexity of the project we have to scrap all that code. Custom classes will make everything we needed done so much easier and cleaner.

My 2 Cents :
I MUST say that I totally agree with this comment. In essence I believe that classes are more natural, cleaner and in the long run - you can just embed more knowledge in them. Data sets are containers - classes are the model. I also believe that the class approach - you continually refactor and the solution is flexible - not rigid… Again - I am just biased - someone compel me for datasets….

DataSets vs. Collections

excerpt:
Both DataSets and custom classes don’t limit what you can do in any way, and both can be used to accomplish the same aims. That said, DataSets are fantastic tools for prototyping applications and represent excellent solutions for building systems in a kind of emergency—a limited budget, an approaching deadline, or a short application lifetime. For relatively simple applications, custom entities add a perhaps unnecessary level of complexity. In this case, I suggest that you seriously consider using DataSets.In the economy of a large, durable, complex enterprise system that takes several months to complete, the cost of architecting and implementing a bunch of collections classes is relatively minimal and is incurred only once. The advantages in terms of performance, expressivity, readability, and ease of maintenance largely repay the investment. You are not bound to a tabular rendering of data. Business rules and custom business entities can’t always be adapted to look like a collection of tables. In general, you should avoid adapting data to the data container—quite the reverse, I’d say. Finally, using custom classes makes for easier unit testing because classes and logic are more strictly related than with DataSets.

My 2 Cents :
Dino is the man 1st off - 2nd - I REALLY agree with this statement as just about the best summary of all. This is what I truly believe. Dino also mentions generics in 2.0 and how much stronger the argment for classes/ collections becomes under the 2.0 framework…..

On the Way to Mastering ASP.NET: Introducing Custom Entity Classes

excerpt:
There are a number of situations for which DataSets are particularly well suited, such as prototyping, small systems, and support utilities. However, using them in enterprise systems, where ease of maintenance is more important than time to market, may not be the best solution.

My 2 Cents :
Man - I could excerpt this entire article. Read it - it really sums up my viewpoint as well.

DataSets Are Not Evil

excerpt:
Ok that’s it, everybody stop talking smack about the DataSet. As self-elected chairman of the inexistent “DataSet Preservation Fund”, I feel urged to respond to years of incorrect positioning, biased thinking and over-simplified black-and-white views. I won’t allow the “enterprise community” to make the DataSet the Clippy of .NET, so to speak.

My 2 Cents :
THis guy basically takes the other side of the “On the Way to Mastering ASP.NET: Introducing Custom Entity Classes” article - he does a weak job if arguing frankly…. Someone show me the dataset side of the argument please.. Still dont see it.

Returning DataSets from WebServices is the Spawn of Satan and Represents All That Is Truly Evil in the World

excerpt:
DataSets are bowls, not fruit. Do you really want to return bowls?

A DataSet is an object, right? But it’s not a Domain Object, it’s not an “Apple” or “Orange” - it’s an object of type “DataSet.” A DataSet is a bowl (one that knows about the backing Data Store). A DataSet is an object that knows how to HOLD Rows and Columns. It’s an object that knows a LOT about the Database. But I don’t want to return bowls. I want to return Domain Objects, like “Apples.”

My 2 Cents :
Yes yes yes…. Yes yes yes…

Datasets vs. Custom Entities

excerpt:

• They are very bindable. (I will give the dataset folks this - the tools do provide this. There are ways around it however - 2.0 has the ObjectDataSource and Infragistics has the excellent - WinDataSource that is useful to make ‘objects’ bind to grids easy as pie.)
• Easy persistence. (IF you are directly connecting to the DB….)
• They are sortable.(yes)
• They are filterable.(yes)
• Strongly Typed Datasets defined by XSD’s.(yes… better but 99% the rest is the same to me.)
• Excellent XML integration.(eh, I guess so.. still not ‘nice’ XML. It is generic XML - not XML for your nice object.)
• Computed Columns (OK - objects do this all the same - just as well - or better depending.)
• Relations (OK - objects do this all the same - more explicitly I would say)
• Data Validation (OK - objects do this all the same - mostly better)
• AutoIncrementing values (OK - objects do this all the same - this is trivial)

My 2 Cents :
OK - this guy has the BEST set of arguments for the dataset way. I do hear the arguments to some faint degree - but - not very strong still.