The Franciscan Report

Framework Abuse - Dragos Manolescu

I couldn't agree more with Drago's accessment on this subject. Problems that I have seen in the past were:
- People don't know the meaning of "framework", the best definition of framework is the one written by Prof. Ralph Johnson (one of the GoF). He wrote that, a framework is a reusable design of all or part of a system that is represented by a set of abstract classes and the way their instances interact.

- From the misconceptual thinking of the framework, people tend to put "everything" in the framework, things that might not even be related.

- Rarely did I find framework with good referential implementation. As a result, either the consumer of the framework misuse it or doesn't even know such a feature exists.

- Frameworks were rarely updated, this of course can cause problems, since a stale framework might not serve the need of the consumer anymore down the line.

- Not enough "publication" or "evangelism" effort for the framework causing the framework to be abandoned.

- Not working together with the consumer causing people to develop frameworks that were hard to use, and didn't serve the consumer needs.

I'm sure there are a lot of things that I could have list here ...

ArticleS.MichaelFeathers.ItsTimeToDeprecateFinal

I couldn't agree more with Michael Feathers. Martin Fowler have discussed this in the past also. In his article he mentioned that there are two types of developers, the enabling one and the disabling one. An enabler, would probably be the type that would not restrict his code by introducing final excesively.

This is not to say that restriction is bad, because some restriction like private modifier is good for encapsulation.

On the weekend I was experiencing the problem in my .net code.

Here's a snippet of the code

System.Reflection.Assembly lib = System.Reflection.Assembly.LoadFrom("MyAssembly.dll");

object obj = lib.CreateInstance("MyType");

The obj instance turns out to be NULL, so I was really surprised, since I was able to find the MyType inside the MyAssembly.dll.

After spending hours of debugging, it turns out the "real" problem is, MyAssembly.dll depends on other assembly that I didn't include in the path.

Obviously any good developer should know, that returning a null doesn't really tell you or help you out, where as throwing exception with the exact information might. I would expect better code written especially for a Framework that's widely used.

In life we're always faced with a decision whether to react to something when it happens, or create a governance to prevent the thing to happen in the first place.

Pros and cons of reaction
- Reaction allow you to react on things, thus it gives you opportunity to come up with simple solution just enough to solve problems at hand.
- Sometimes it could cost a lot of money if we miss handled things that are critical to business operations.


Pros and cons of preventive action
- Preventive action is good to prevent things that we think might happen from happening based on our previous experience, etc.
- It can be overkill since every situation/environment is unique, and sometimes preventive actions introduced might not be suitable and it can be come overkill at worst. There's nothing more frustrating than come up with an overkill solution that slow down the process, and it will be even worse if people try to solve it by adding more preventive actions

My preference is to start with simple preventive action, based on the things that we know might break under common conditions, and react to any problems later when we face them.

Interface based programming has been around for a while, but yet, the adoption of it hasn't been widely accepted by most developers.

When people think of interface, they think of all the disadvantage of using it such as;
- adding new methods/changing existing methods to an interface forces implementer of the interfaces to have to implement the new methods too
- once interface is published it's thus set and we can only extend the interface by creating newer interface that will extend the old one

Although these are all valid points, but the benefit of using interface outweight the risks.

Some of the benefits are:
- Open and Close Principle
- Dependency Injection
- Interface Segregation Principle

As we all know from old principle that we usually use the interface more than we actually extend it ourselves.

One solution we could incorporate to ease the risk mentioned above (only if you need to extend the interface) is to always provide a base class together with the interface that we provide, thus user of the system has freedom to choose.

In most cases clients are only referring to the interfaces instead of extending them

Microsoft Framework team introduces a pattern called "Aggregate Component" which has a similarity to a Facade pattern.

The purpose of this pattern is to enable user of the framework to only deal with one simple component to accomplish a particular task, ie. message queueing etc.

User of the API doesn't have to care about other components that have been encapsulated inside the "aggregate" component.

Some concerns of this approach are:
- It allows users to create object in inconsistent state, which can be remedied by throwing an exception when a user try to call the object with invalid state.
- The component settings need to be done in simple way, providing a lot of default value, otherwise, the benefit is reduced.
- It works well for entry level user, since, some of the default settings might not promote the most efficient way of using the framework.

Answering the "Where is the Proof That Agile Methods Work" Question

"Agilists don't write documentation"
This is further from the truth, although I agree that some of the "extremme" Agilist do ignore documentation. But that's not the point, the point is Agilist believes in DRY principle (www.agilemodeling.com/essays/singleSourceInformation.htm). Agilist actually have a lot more documentation, such as the unit tests, acceptance tests, and if the stakeholders are willing to pay, Agilist will definitely provide a high level overview, system models, user documentation, etc. The key is not to get lost in just providing documentations without a real software, and to always keep track of where the time/money goes in software development phase (sometimes documentation time is not tracked)

"Agile teams don't need project managers, quality assurance people or architects"
This is only half true, Agilist support the notion of "Object should be specialist, and Developer should be generalist", member of Agile team should be able to wear multiple hats. Every one should be part of ensuring the quality of the system, and design is more of a collaborated effort than something bestow by an ivory tower architect team. (www.agilemodeling.com/essays/agile Architecture.htm)

"Agile cost-of-change curve is flat"
This is supported by the fact that Agile methodologies adopt short iterative cycle releases, thus any problems should be detected sooner and client feedback is a must in every iteration leading up to the release. (www.agilemodeling.com/essays/costOfChange.htm) The key to agile success is always feedback and the sooner we get the feedback of the system the better chance we have for the success. Feedback comes from the developer to proof that his/her idea works, from the tester, from the client. (www.ambysoft.com/essays/whyAgile WorksFeedback.htm)


Reference

Crossing the Chasm, Scott W. Ambler, SDMagazine May 2006

The three most common questions asked by your boss/client before you undertake a project are;

1. Can you do it?
2. When can you do it?
3. How much it will cost me?

These questions are hard to answer because there are different obstacles facing a project during its lifetime, such as;
1. Change is sometimes inevitable
2. How can we handle the unknown?
3. Can we get commitment and clear direction from all stakeholders?

In order to ensure that a project will be on track, we must:
1. Assemble the right project team, people on the team should have a good working harmony
2. Have support from all stakeholders
3. Ability to control the scope, decide which one is a must have or nice to have, and capture nice to have for later release
4. Must have iterative releases, since it will give the stakeholders a sense of progress and opportunity to provide feedback
5. Must have active client involvment

Reference

Project 911, Donna L.Davis, SD Magazine May 2006