Why should you care about Technical Debt?

Let us look at the product life cycle of an optimal software product (software that can be modified and tested with minimal effort) and a software product with high technical debt.

The above graph shows a plot of Cost of Change & Customer Insterest in the product against Time. The reason why the customer interest in the product keeps decreasing is that the higher cost of change makes it more difficult for new features to be  implemented and at a faster rate. Longevity of a software product with higher technical debt is actually lesser compared to the optimal software product. This is because the product is never allowed to mature feature wise and also as the higher technical debt makes it difficult to keep it alive. This mostly results in early retirement of the product.

Martin Fowler had defined the types of technical debts using a Technical debt quadrant as shown below.

The types of technical debts are:

1. Reckless and Deliberate debt: This is the debt produced by many teams where they know that the right way to do it, but choose to go with the quickest way and never return to fix it. Schedule pressures, short sightedness and not understanding the cost of messy designs are some of the major forces that cause this type of debt.
2. Reckless and Inadvertent debt: This is the debt that programmers that just don’t know what good design is and are doing their best. This can commonly happen when you are new to a technology, but do not go out and find information from others in the industry.
3. Prudent and Deliberate debt: This is the type of debt where everyone understands the cost of choosing the quicker approach and weighs that against the short term benefits of taking on the debt. Schedule pressure does play a factor in this type of debt. Without careful focus on repayment this will quickly become Reckless and Deliberate debt.
4. Prudent and Inadvertent debt: This is very close to the Reckless and Inadvertent debt, but there is no one that has the knowledge you had to go through making the mistakes to know what is the right thing. This can happen when you are the first team using a technology at a scale that no one else has. Once you understand the better way to do something, if you don’t incorporate that into your work this debt will again quickly swing to the Reckless and Deliberate kind.

Having known about what Technical Debt is, let’s have a look at the common causes of Technical Debt

As you can see Technical debt can occur at any phase of Software Development Life Cycle.

And the effects are…

If you notice some of the above effects in your organization, then you should start thinking about how to repay the technical debt. If you start thinking about paying back, then you can look into some of the options listed in the below figure. Based on your choice, if you chose the first two options then some of the possible actions that you need to take are described below in the same figure.

Here is Ward Cunningham’s analogy of Technical debt and Financial debt

• Skipping design is like borrowing money. (I like “writing code” better than “skipping design” here — JimLittle)
• Refactoring is like repaying principal
• Slower development due to complexity is like paying interest
• When the whole project caves in under the mess, is that like when the big guys come round and slam your hands in the car door for not paying up?

In VBA we create macros in VB6. In VSTO we create .Net assemblies in C#. However, unlike VBA, where the code is stored in the document file itself, programs written with VSTO are stored in separate .NET assemblies which are associated with the documents by means of custom properties. At runtime, that assembly is loaded on the fly.

As the nature of VSTO, the customization code is stored separately in .NET assembly (*.dll file), that can be deployed to a central location and all the documents just link to it. Updating can be configured so it can be checked every time the document is opened, or by specific period.

VSTO can access many application level functionality of Excel, such as Ribbon, Custom Task Panes, etc. Using VSTO, you can develop application level add-in that will always be available regardless opened document. VSTO makes it even easier by providing a Ribbon designer that makes adding new tabs, groups, and controls to the Ribbon as intuitive as adding a control to a Windows Form.  By contrast, VBA customization is document level.

Like any .NET projects, you can use Source Control server like Team Foundation Server (TFS) to facilitate collaborative development for VSTO-based project. All VSTO project artifacts can be checked in/out to/from TFS server, including Office document (xls, xlsx, doc, docx, etc).

Since VSTO is a part of .NET, it inherits technologies like WCF. In other words, it’s easy to develop VSTO Add-In to access XML Web Services.  And all that functionality is built into VSTO. But this is not built into VBA.

MVVM is more loosely coupled than MVP. In MVP, the View implements an interface IView and the presenter uses this interface. Since each view is different, it makes less sense to make each view implement the same IView interface. We might end up creating separate interfaces and Presenters for each view. With MVVM the view is aware of the viewModel, and the viewModel is aware of the model (but not vise versa). This means that multiple views can use a ViewModel and multiple ViewModels can use a Model. Hence MVVM is loosely coupled than MVP.

MVVM utilizes the features of WPF such as Data Binding, Commands, Data Templates. WPF (and Silverlight 2) features make MVVM a natural way to structure the application. This is not the case with Winforms.  Although Winforms supports databinding, you need to write some extra code to support two way data binding in Winforms by implementing INotifyPropertyChanged interface.  In the case of MVP, there is no need for two way data binding. The Presenter does the job of updating the view. You can also try creating a command manager for supporting Commands for MVVM, but it is much harder. Winforms do not support Data templates.  You can make Winforms support MVVM but you might not get all the benefits  of using MVVM in WPF.

If MVVM is properly used it is more testable than MVP.

The descision to use MVVM for Winforms is still up to you, based on your project needs.

Below are the few links I referred:

Niraj Bhatt on MVC vs. MVP vs. MVVM

Safe usage of INotifyPropertyChanged in MVVM scenarios

MVVM/Presentation Model With WinForms

MVVM for Winforms

MVC vs. MVP vs. MVVM

Are you a project manager who wants to introduce some agile practices into your software project?

Are you a programmer or software architect ? Do you need the technical details you need to get agile?

Are you wondering how to combine the latest agile techniques with more traditional up-front requirements analysis + design to increase the likelihood of your project succeeding?

The ICONIX Process would be a useful starting point.

What is ICONIX Process?

ICONIX is a open, free-to-use object modeling process. It’s minimal, use case driven, and agile process. The ICONIX Process is a minimalist, streamlined approach that focuses on that area that lies in between use cases and code. It uses a core subset of UML diagrams, and provides a reliable method of getting from use cases to source code in as few steps as possible. ICONIX is a sweet spot between light- and heavyweight software development processes.

ICONIX is a software development methodology which predates both the Rational Unified Process (RUP), Extreme Programming (XP) and Agile software development. Like RUP, the ICONIX process is UML Use Case driven but more lightweight than RUP. Unlike the XP and Agile approaches, ICONIX provides sufficient requirement and design documentation, but without analysis paralysis. The ICONIX Process uses only four UML based diagrams in a four step process that turns use case text into working code. If you find the Rational Unified Process too large, and Extreme Programming too small, take a look at the use case driven ICONIX process, which sits nicely in the middle.

A principle distinction of ICONIX is its use of robustness analysis, a method for bridging the gap between analysis and design. Robustness analysis reduces the ambiguity in use case descriptions, by ensuring that they are written in the context of an accompanying domain model. This process makes the use cases much easier to design, test and estimate.

The ICONIX Process is described in the book Use Case Driven Object Modeling with UML: Theory and Practice.
Essentially, the ICONIX Process describes the core “logical” analysis and design modeling process. However, the process can be used without much tailoring on projects that follow different project management or agile methodologies. Because the process uses a minimal set of steps, it’s also well suited to agile development, and can be used in tandem with test-driven development (TDD) to help “plug the gaps” in the requirements. If you combine unit testing with up-front UML modeling, you can produce a really rigorous software design. The book Agile Development with ICONIX Process describes how to use the ICONIX Process in an agile project.

ICONIX Process and Water fall process model

ICONIX Process describes a series of specific steps that were found work really well on many different software projects. However, it doesn’t prescribe the project life-cycle side of things in the way that most other software development methodologies do. You can be as agile (with short iterations and quick, successive releases) or as “waterfall” (first writing all the requirements, then doing all the design, and then writing all the code) as befits your project, and still be following ICONIX Process.

ICONIX goals of Agility

ICONIX Process’s Agile Practices Vs Standard Agile Practices

– With ICONIX Process, an emphasis is placed on getting the software requirements right up front

– With ICONIX Process, design modeling and coding are tightly interleaved, each providing feedback to the other

– With ICONIX Process, the design and the code don’t diverge over time. Instead, they converge, with the design model and the code becoming more in sync.

Top 10 Things why People who use ICONIX like it

10. The process uses a core subset of UML.
(We’d rather learn 4 diagrams than 14 . . .)

9. It actually gets me all the way to code.
(I have 13 use case books on my shelf that don’t get within 50 miles of code.)

8. It’s traceable from one step to the next.

7. It addresses both sunny- and rainy-day scenarios.
(If another one of my programmers tells me they’re “Doing The Simplest Thing That
Could Possibly Work” [DTSTTCPW], I think I’m gonna scream.)

 

6. It assumes that the requirements I’m initially given are vague, ambiguous, incomplete,
and incorrect.

5. It actually drives the OO design from the use cases.
(I know RUP says that it’s use case–driven, but I get lost somewhere around the Elaboration
phase.)

4. It works well in an “agile” (short iteration, small increment) environment.
(I wish somebody would write a book on how to do Agile/ICONIX, though.)

3. It doesn’t drown me in five-syllable buzzwords.
(What about multiple polymorphic inheritance, anyway?)8

2. It operates at a tangible level where the use cases talk about what the users are doing on
the screens, and there are no huge use case templates.
(In other words, the use cases aren’t abstract, essential, technology-free, or implementation
independent.)

1. It’s a practical approach that’s been proven to work in the real world, on hundreds of
projects.

Jason Dolinger has written a blog on Model-View-ViewModel in WCF. The blog has a video attached. In the video he talks about how to create Testable WCF applications.
Jason Dolinger on Model-View-ViewModel

Here is a brief summary of Jason Dolinger’s presentation

XAML is tightly coupled with the code-behind file. We usually write all the logic in event handlers in the code-behind files. This tight coupling of code-behind code with the UI will make the unit testing the code difficult. One more problem here is the View or the UI has become the storage place for data. Whenever you need some data you go to the UI controls to get the data. The View must just display the data and must not be storage place of the data.

Jason also talks about Model-View-Presenter pattern and how it is used in Winform/ASP .NET. In MCP, the Presenter acts as a controller. The view implements an interface. The Presenter is instantiated in the code-behind and an instance of the view is passed (injected) into the Presenter via the view interface. The presenter class is testable. You can create an instance of the Presenter, create a mocked view and pass it to the presenter. You can write tests against the methods in the presenter. The code-behind stays clean. MVP will also be applicable to WCF. But with MVVM we can take advantage of WPF two way data binding. Also you can avoid creating interfaces and implementing them.
In M-V-VM thee are three entities Model, View and ViewModel. View Model is a standalone C# class which acts like an adaptor between the View and Model. VM retrieves the data from the Model and displays it as properties. The view is databinded to the ViewModel properties (hence called the adaptor). VM contains public properties for each control in the View.

You can also refer A Practical Quick-start Tutorial on MVVM in WPF – CodeProject

I also came across an article that says using MVVM might be an overkill for small applications.

This links talks about an alternate implementation (MVP-PMlight approach)- The MVVM Pattern Is Highly Overrated

There are some guidance from Patterns and Practices about using Prism for WPF

 Prism, CAB, and WinForms futures

patterns & practices: Prism

]]> http://sureshkumarveluswamy.wordpress.com/2010/07/28/mvvm-design-pattern/feed/ 0 sureshkumarveluswamy mvvm http://sureshkumarveluswamy.wordpress.com/2010/04/10/wcf-performance/ http://sureshkumarveluswamy.wordpress.com/2010/04/10/wcf-performance/#comments Sat, 10 Apr 2010 10:18:27 +0000 Suresh Kumar Veluswamy http://sureshkumarveluswamy.wordpress.com/?p=3 ]]> WCF Performance

Some of my colleagues have been asking me questions like, Why should we migrate to WCF? Will WCF provide better performance than what I have? After some research, I found some performance comparisons that would justify migration to WCF.

I came across a Microsoft post for WCF performance comparison with other available choices. It is available here: A Performance Comparison of Windows Communication Foundation (WCF) with Existing Distributed Communication Technologies

The article compares the WCF to Web Service (asmx), WSE 2.0/3.0, Enterprise Services and .NET Remoting.

To summarize the results

WCF is 25%—50% faster than ASP.NET Web Services, and approximately 25% faster than .NET Remoting. Comparison with .NET Enterprise Service is load dependant, as in one case WCF is nearly 100% faster but in another scenario it is nearly 25% slower. For WSE 2.0/3.0 implementations, migrating them to WCF will obviously provide the most significant performance gains of almost 4x.

.NET offers several different flavors of WCF services that you can choose from based on your particular needs. Now, If you have decided to go for WCF, you will have the  next question. Which flavor of WCF should I choose?

You might be interested in some performance comparison before choosing a particular flavor. I found a blog that does this. It’s WCF Latency Test Harness and WCF Performance.  This shows measures of WCF performance by varying different parameters.

To summarize the results

nullTransport, netNamedPipe and netMsmq Bindings show better performance than basicHttp and wsHttp Bindings.  .NET Remoting shows better performance using the default DataContractSerializer when using a more complex data structure.