Chris Donnan

Slice the Work Vertically, Not Horizontally .. IoC/DI Frameworks

I have been debating with a client about how to 'slice up' the implementation of a piece of software development/ refactoring. Some folks on the client team were advocating what I consider to be a fairly deadly approach to developing software. They were basically advocaing a waterfall-ish approach to developing the software... Build the backmost layer 1st, then the next, the next, you get to the UI in the end, etc.

I stumbled across this http://codebetter.com/blogs/jeremy.miller/archive/2005/11/26/135098.aspx blog entry from Jeremy miller. He is on my feed list these days.... And I quote....

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.

My Gabe (Left-most) and his school best buddies!!!

Love this

Good Agile Dev Article

Model/ Domain Objects vs DataSets

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.

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....

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.....

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.

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.

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...

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.

Microsoft Lauds 'Scrum' Method for Software Projects

Why coding standards??????

• 80% of the lifetime cost of a piece of software goes to maintenance.
• Hardly any software is maintained for its whole life by the original author.
• Code conventions improve the readability of the software, allowing engineers to understand new code more quickly and thoroughly.

• Avoidance of errors/bugs, especially the hard-to-find ones.
• Maintainability, by promoting some proven design principles.
• Maintainability, by requiring or recommending a certain unity of style.
• Performance, by dissuading wasteful practices.
• Rules and recommendations are given that promote reliability and maintainability.

Code standards, casting and other bags o' worms

  class Foo
  {
    private int _aThingId = 0;
    // vs.
    private int aThingId = 0;
    ...
    ...
  }

  class Foo
  {
    private void DoSomething( object foo )
    {
       Foo f = foo as Foo; //(null check later for invalid cast - no exception)
       // vs. (potential invalid cast exception)
       Foo f = (Foo)foo;
       // or
       Foo f;
       if( f is Foo ) 
           f = (Foo)foo; 
    }
    ...
    ...
  }

  class Foo
  {
    private int val = int.MinValue;

    /// this is OK by me and all others 
    public Foo( int val )
    {
        this.val = val;
    }

    /// this is NOT OK by me and many others
    public void DoSomething()
    {
        if( int.MinValue == this.val )
        {
            //Do something useful
        }
    }
    ...
    ...
  }

Lowly Blog Value!!

I Got the Clearcase/UCM Blues too