Anti-pattern for October Franken Code

Anti-pattern for October Franken Code

The title of the Anti pattern is Franken Code, the sub-title is” It's alive! What could go wrong”

The elaboration is read as:  Code consisting of bits and pieces of other, possibly unrelated, code that only barely performs its function and is prone to error. Much like Frankenstein's monster, such code can wreak havoc on users

http://deviq.com/frankencode

This link provide some further reading on the anti-pattern (including an interesting photo). For your convenience, I copied some here:

Frankencode refers to code that was never designed to work together, being pulled into a single application and held together with duct tape, baling wire, and maybe some Adapter design pattern usage. While software reuse and compatibility are desirable, frequently software that has been developed independently is written using incompatible assumptions and design decisions. Thus, when integrated together, the result can be clumsy and poorly architected, at least when compared to software that was designed to work together within the problem domain being considered.

 Quotes

"...learn from my miseries, and do not seek to increase your own." - Mary Shelley, Frankenstein

The following is a story a close friend of mine told me:

Not long ago, I came across a  Web application. The project was established as a fixed bid contract by iterative delivery scheduled on features. in each iteration. The developers are working hard just for that feature assigned to him or her. There was no refactoring effort, no design effort, and you guessed, no unit test case as well. Just coding and coding...

I have tired very hard to tell the engagement lead, project manager and the "Solution Architect", ( I put the quotes on the solution architect, as it is a Net project, but the solution architect is a Java guy who could barely able to move around within Visual Studio) that this would create problem down the road. with feature based iterative delivery, without refactoring, you would have a collection of disorganized code block; without automat unit test, refactoring would be very risky to the stability of the codebase.

 

3 months into the project, we got a codebase with lower performance, low maintainability and high cyclomatic Complexity. From vertical point of view, each feature looks like the only feature in the system. From horizontal point of view,  All methods and classes look disorganized to the extend beyond anyone's imagination.

In this project, they did not get the Franken Code from somewhere else, they produced Franken Code themselves.

Ok, This is the story I got about producing your own Franken Code.  in Software development business, loosely coupled and high cohesive are every architect's goals. If you are doing traditionally water fall process, do have a proper design after you collected all requirements; if you are doing agile or any feature based iterative delivery, Collective ownership, unit test and refractory are your best friends. if you are taking bites from other source like Nuget or download them from the internet, that is fine as we all do that. but you need to do it with your eyes open. the following are some important aspects to be aware of when you do that:

1. you want to get something in the framework level, for example, the library to interact with Web Api service, the library to interact with database. you would not want to get a third party package take care of your business logic.
2. you want to get it from reputable source.  Microsoft, Nuget.org, Codeplex, GitHub
3. you want to get the package that is meant for the net framework version and the visual Studio version. any compatibility issue would cost you trouble down the road
4. you want to review the code after you get them into your project

  

   

   

Anti-pattern for September The Blob

The title of the Anti pattern is The Blob, the sub-title is” Doing everything all at one is a best practice”

The elaboration is read as:  A class in an object-oriented system that monopolizes the processing while other classes primarily just encapsulate data. this results in software that is more complex and harder to troubleshoot and maintain.

http://deviq.com/the-blob

This link provide some further reading on the anti-pattern (including interesting photo). For your convenience, I copied some here:

The Blob is an anti-pattern that describes a class which resembles the monster from the 1958 film The Blob, which absorbs anything it touches and grows larger and larger over time. Such classes are similar to God Objects and over time lose any focus they might once have had. Blob classes violate well-known OOP principles such as the Single Responsibility Principle and the Open/Closed Principle, and tend to be more expensive to maintain and lead to Big Ball of Mud systems.Rather than allow a class to expand like The Blob, refactor using Extract Class and create smaller classes that each have a single responsibility.

 Quotes

"Multitasking is the art of distracting yourself from two things you you’d rather note be doing them simultaneously.”

- Anonymous

 Not long ago, I came across a  windows application. The application handles 3 different categories, more than 170 different transactions for a state government agency. There are distinguished business rules, processes for transactions in each category and specifically in each transaction.
For each transaction, there are 5-10 steps user need to go through to complete the transaction. Steps for different transaction category and different transaction are different and configured in a database table.
However, in the design I saw only one Window Form named as Transaction Detail Form, which is used to handle all different transactions in various steps.
Similarly in the business layer, I saw a huge class call Transaction Business Object, it has over 8 thousands line of code,  close to 500 members.  the highest member level of cyclomatics Complexity is over 170 (it was over 1000 when I took it over)
This is a clear case of “The Blob”, Transaction Detail Form and Transaction Business Object are two biggest Blobs among the rest.

Sure enough,  it is easy to break, hard to maintain and very difficult to troubleshoot.
In object oriented design,  the rules you want to follow are: 1) No repeating logic 2) no redundant functionality. In this case when a Business Object is instantiated to handle one specific step of one specific transaction, the object is much powerful than the task it is given.  when you change something in the class for one specific transaction, unintentionally, the code change affect other transactions.

Wen you are in the design phase, pay attention to the rule of “one thing and one thing only”, when class handles to many functionalities, you want to break it to smaller classes. When you design class model, you want to give each class a specified scope and role in the system.

When you are given a code base like the one I had, you want to be careful bot to break existing functionality while you take effort to fix the Blob issue.  What you want to do is to design a new set of object inheritance hierarchy and make the original Blob class be the base class and let the rest of code base use these sub-classes where the blob class was used originally.  I am sure you want to give each sub-class a clear defined scope and role.  At this point of time, all sub classes are empty. all we are doing is to create place holders for various sub classes. because there is no business logic changes, the change is less risky, even if we forgot to change some reference, it is fine, as the functionality is still in the original blob class. a good test to see if you have completed this step is making the originally blob class an abstract class. if you are able to do that without build error. you are good.

Once you are done with that, you can start to move business logic specific to certain transaction or specific to certain step to its rightful home in the newly defined object hierarchy.  as you slowly making progress in this migration process, you will see the blob class start to shrink, and these empty sub-classes start to have something meaningful.

However, this is the technical aspect of the issue,  to achieve what I described here you must not  underestimate the non technical aspect of the issue.  The leadership’s recognition of the issue and commitment to resolve the issue are critical.  Like basketball game, it is a team sport, and all listen to the coach. if coach does not believe the shooter is tired or not performing well, he stays on the game. If you, as a team member, making too much noise, you might get yourself out of the game. Similarly, if the leadership does not believe this is the problem, the problem will stay.  The worse thing is that the longer the problem stays the worse the problem will be and the bigger negative impact on productivity. this is what I call "too busy to do something to save time."
 

Announcement of Windows Store App and Windows Phone App Development Blog

Hi, All,

I took the effort to reorganize my blogs. with that effort I created 2 new blogs, one for Microsoft Mobile App development ( windows Store App and Windows Phone App); One for Apple iOS app (iPad and iPhone) development. I have migrated most of relevant posts to these 2 new blogs and I will continue the migration process.

  http://peterlumsmobile.blogspot.com/

http://peterluios.blogspot.com/

http://peterludotnet.blogspot.com/

http://peterlusql.blogspot.com/

http://spellingchampionapp.blogspot.com/




these are the links to the newly created blogs and 2 other blogs, Enjoy and your comments are most welcome.


Thanks.

Inversion of Control (IOC) and Dependency Injection (DI)

For some time, I wanted to write something about this topic. it was largely due to my laziness, until now.  well. I guess I overcame my laziness today, and took the effort to get to this topic…

in most of program we write, there are always 2 parties involved, namely provider and consumer. when you write a method which instantiate another class and invoke a method of the instantiated class,  the code you are writing is the consumer, and the class you are instantiated is the provider. the same class in different context could switch its role between consumer and provider.  however, there is one common characteristic between the consumer and the provider, that is the consumer have the control and calls the provider.

Inversion of Control ( IOC) is a mechanism by which the control been transfer to the provider, in another word : let the provider take the control.  the over all goal of IOC is to break the dependency between the consumer and the supplier and yet let them communicate freely. if you take a closer look at the IOC implementations, you will find there are a few different implementation of it. I am going to list them below and give some of them some more detail elaboration on some of them:

Delegates

most of modern programming language supports Delegates, with the exception of Java.  if you look back at any declaration statement 

People myManager 

People is a class defined somewhere else, myManager is a variable can take any instant of People class. 

in 

DayEndOperation myDayEndOperation 

DayEndOperation is a Delegates defined else where, and myDayEndOperation can take in any instance of DayEndOperation

like in the class case, you can invoke the method or property of the class by myManager.Name or myManager.Approve ( yourRequest). in the case of delegate, you can invoke the delegate. you can pass around the delegate as parameter. This is very important as you create a delegate from consumer class and pass it to a method of the suppler class. and let supper class decided when and where to invoke it. 

Event 

Event is a special application of Delegate.  the suppler class defined certain events, when the consumer class instantiates the supplier class, the consumer class get to defined event handlers to react to these events. in the course of execution of the suppler code, the supplier class fire up certain events and in react to the firing of the event, the consumer’s event handling logic get executed.  the key is the supplier took over the control and calling the supplier code. underneath any event handling mechanism, you will see a delegate as part of implementation.

Dependency Injection

Dependency Injection is a mechanism to break the dependency from the consumer to the supplier by introducing Interface.  in this case, 2 more players got into the picture other than consumer and supplier,   ISuppiler and  container. in compiling time, consumer only depends on ISuppiler instead of the solid implementation of ISuppiler. in runtime, container injects the solid implementation into the interface. the injection could be done in code, or by configuration. when it is done in configuration, that means, in run time I can switch the solid implementation of the interface without recompiling the consumer code. This characteristic make it very good for doing coded unit test, because I can inject some stub implementation into my test method to test my consumer code without calling the real supplier components. there are constructor Injection, Property Injection and Method Injection. most of DI container support all of them.  I personally worked on Unity and NDepend.

Service Locator

Suppose your consumer classes have dependencies on an external service , whose concert types are specified sty compile time. The following limitations are posed to the system:
 1. to replace or update  the external service, you need to update your project reference and recompile the solution
2. the external service must be available at compile time
3. your class is difficult to test in isolation because it need the external service to run


Service Locator pattern introduce another element, call <Service Locator>  and let Service Locator handle the dependency of the external service.  in detail implementation, you could inject different locator to your consumer project, or you inject external service into your Service Locator  or you use Factory Pattern to handle the instantiation of the external service.  if the service provider provides respective interface of the service, DI is preferable, otherwise use factory pattern. this preference is due to the fact, only doing DI you will remove the dependency of concert type of the service and only when the interface is provided, you can do DI.

Anti-pattern for August: Walking in a Minefield

The title of the anti-pattern is: Walking in a minefield. The sub title is “the application’s ready for production… you go first."

The elaboration is read as:  When a product (known to be incomplete) is released prematurely, this forces users to stumble through the system finding bugs while the development team scrambles to resolve them.

http://deviq.com/walking-through-a-minefield

This link provide some further reading on the anti-pattern (including interesting photo). For your convenience, I copied some here:

When software is released before it is ready, and users of the software are made to find all of its bugs and shortcomings, they're made to feel as though they're walking in a minefield. It's important to release software as quickly as possible, in order to minimize feedback loops, but what is released should work so that users do not lose confidence. Each new release should be more stable than the last, and should incrementally add new functionality. If the system is constantly shifting such that things that work one day fail the next, eventually users will demand a different system altogether, and the project will fail.

 Quotes

"Software undergoes beta testing shortly before it's released. Beta is Latin for 'still doesn't work.'" - Anonymous

There is a related anti-pattern, it says “let’s test it in production.”

 

The commonality of them is releasing a untested product to the end user, with the hope that the product is not buggy or if it is buggy, the users will help to identify the bugs for the development team to fix so that the software product can be useable.

From principle point of view, this is not a good practices, when the product is released for production, it need to have some kind of quality standard. Release an untested product to production is not fair for the users or client. It may very well negatively impact client’s business operation and could damage their reputation or expose client to other tangibles damage.

From technical point of view, some bugs could cause loss of data, and the lost data may not recoverable even if the bugs are fixed afterwards.

The biggest risk is that when an untested product exposed to its user, the users might very well discouraged by the buggy product and hence reject the product totally. 

However, in my decade’s application development experience, I have seen many incidences of the anti-pattern. I remember a few years ago, I attended a high level project strategy meeting. The meeting is to establish a strategy to address the issues of lacking of resource and time for developing and conducting test cases during the stabilization phase of the project. To my surprise, the decision was cutting down the number of test cases  significantly. The justification was: there is no enough time.  When I heard that, I could not believe my ear, this is exactly, “let’s test in production”

My take on it is simple, “Never”, never do that! An experienced project manager should be able to project such project risk and mitigate such risk so that it will never become an issue to be addresses in the project.  From technical resource point of view, when you are brought into a project to handle the crisis, you should take positive attitude do your best to recover from the crisis. I personally have been in such situation many times. The advice I could offer are the following:

 

1.    Backup database often, make sure the raw data entered by user is stored in database correctly. In production system, nothing is more important than data.

2.    When patching data error generated buggy logic, make sure the patching logic does not get extended beyond its intended scope.

3.    Fixing bug and patching data need to be in sync.

4.    Apply pair programming to reduce human error.

5.    When fixing bug, do your best to respect the original design and minimize the changes to be made. It is always risky to change design when product is in production.

 

Finally, remember there is no bug is small in production.  You could never be more careful. As the title said, it is a minefield, you do not want to walk in the minefield. When you are forced to walk in the minefield, be absolute careful.   

Anti-pattern for July Flags over Objects

It is 4th July today.  after watching fireworks at Columbus downtown last night and pressure washing my patio and side walk in the morning, I got to sit in front of my PC.

Yes, it is July now, it is the time for Anti-pattern for July.

This is how it goes.

The title of the anti-pattern is : Flags Over Objects

The subtitle is : So easy you can add another twenty options

The elaboration for the anti-pattern is:  instead of using objects, Polymorphism, or delegation, a flag is added to the class and exposed for public consumption. this often leads to many flags being added in lieu of more maintainable code.

The quote is “ The best thing about a Boolean is that even you are wrong, you are only a bit off”

 The link to the anti-pattern is http://deviq.com/flags-over-objects

The Flags Over Objects anti-pattern occurs when behavior is written outside of an object by inspecting flags (such as status codes), rather than within the object itself. This violates the Tell, Don't Ask principle, and results in chatty interfaces and distribution of behavior that probably belongs within the object. Working around this issue, one will often experience the Shotgun Surgery coding smell, in which many small changes to many files are required in order to make changes to the system. There are many ways to address this anti-pattern. In the worst cases, the State design pattern can effectively be used to bring all state-transition related behavior into the object, or at least into objects specifically constructed to handle the responsibility of state and state transitions.

Take an example, if you see one class  (Transaction Business Entity) representing many business transactions and a flag (Transaction Type) as a public accessible property indicting which business transaction it is, you are in front of “flag over objects” anti-pattern.
it seams intuitive and easy to have this type design  when you add first flag to the class. but before you realized you will be attempted to added more and more.  on the other end, you will have many places making logic decisions based on the value of the flags.  that is where the bad smell comes out. First of all,  these  conditional logic are all over the places ( outside the class), secondly, it is more than likely they got repeated in different places. it is commonly recognized that code in that nature is difficult to debug, difficult to change.  Due to  large number of conditional logic, the cyclomatic complexity of the codebase will go no way but high.
On the other hand, one of the characteristics of OOP is lack of conditional logic.  When new business transaction types are added to the codebase, instead of introducing flags or switches,  sub-class, interface or delegation are used, in the beginning it could be seen as lots of more work as comparing to using flags. but the effort spent on proper OOP design will pay back in the long run. I promise you, your successors will sure thank you for handling them  more maintainable codebase…
So the proper pattern is : Object over flag.  whenever you see a flag or a enum type of property, you ask yourself,  is this indicating the same thing with different characteristic or different thing all together.  if the answer is the second one, you are highly encouraged to consider other OOP technics like objects, Polymorphism, or delegation in lieu of the flags.

FW: Compact DB, Smart Client and Application Caching

Around June 2004, Microsoft released Smart Client Architecture and Design Guide, in the article, Microsoft listed 3 important characterizes of Smart client application:

 

1. It offers rich user experience like normal window application, unlike normal web application
2. It works in disconnected mode. ( MS call it Occasionally Connected)
3. It can be deployed by “no-touch deployment” technology and capable of self-update

 

An example would be like a salesman carries his laptop walking into his customer office, he should be able to show the product catalog, take orders  when talking to his customer  when the laptop is disconnected.  However the orders will be uploaded to the ERP or MRP system, and you should be able to synchronize the product catalog  when he get back to his office and connect the laptop to the company network.

 

To make it possible for the application to function in disconnect mode, the application needs to stored it transactional data and reference data…  To facilitate this kind of functionality, Microsoft introduced concept of Compact DB and database synchronization framework.

 

On the other end, around April 2003, Microsoft release Caching  Application Block as a member of Enterprise Library ( in fact, Avanade is the company behind all enterprise Library development, and I happen worked for Avanade for 3 years from 2004 to 2007). http://msdn.microsoft.com/en-us/library/ee957904.aspx

 

This is what it says about caching, “Caching techniques are commonly used to improve application performance by storing relevant data as close as possible to the data consumer, thus avoiding repetitive data creation, processing, and transportation.”

 

Okay, enough stuff about Microsoft technologies. Let’s move on to our life, BAM. First of all, I have reviewed all non-functional requirements of MI VBAM, it was not our goal to design and develop a smart client. It was not our goal to make it still functional in disconnected mode.    But we are using Compact DB and database synchronization framework.

 

If you look at the data that is been synchronized, you will find more than 70% of data is not supposed to be changed, the other 30% is just some reference data, there is no 2 way synchronization needed. no transactional data is involved in the synchronization process. Basically, we use it as caching solution.

 

To give you some feel about what kind of data we are loading to the compact DB and involved in the synchronization process, I list some tables ( not complete list, in total there 333 tables ) as following:

 

1. REF_CUSTOMER_TYPE
2. REF_ID_TYPE
3. REF_CONTACTS
4. REF_ADDRESS_TYPE
5. REF_STATE
6. REF_CITY
7. REF_SUFFIX_CODES
8. REF_COUNTRY_CODE
9. REF_INTL_MILATARY_STATE
10. REF_INTL_MILITARY_CITY
11. REF_CONTACT_TYPE
12. REF_MODE_TYPE
13. REF_INDIVIDUAL_CHARACTERISTICS
14. REF_BUSINESS_ROLES
15. REF_CITY_ZIPS
16. REF_COST_EXEMPT
17. REF_DAMAGE_REASON_CODES
18. REF_FUEL_TYPE
19. REF_GROUP_TYPE
20. REF_IMAGE_TYPE
21. REF_NAME_TYPE
22. REF_PREFIX_CODE
23. REF_SALE_TAX_OUT_OF_STATE
24. REF_SALE_TYPE_CODE
25. REF_STOP_ACTION
26. REF_TAX_EXEMPT
27. REF_VEHICLE_BODY
    

With that, I am propose the following suggestions

 

1. Review this 333 table to remove these tables that data is not manageable by user. A clear cut would be if we defined a enum in our code, for the same data, we do not even need the data in the server database… please refer to the link https://external1.collaboration.hp.com/external/MIBAM-R1/MI%20BAM%20Cookbook/Enum%20types%20and%20Ref%20tables.aspx for some detail.
2. do away with Compact DB and synchronization framework.
3. Employ Caching  Application Block to cache the data need to be cached in both Client (Process Controller) and server side (BO layer)

 

 

Just so you know,  Caching  Application Block is the application block that is most easy to be employed… 10 minutes would be enough for you to know how to use it… by doing this, the problem we are facing in Compact DB and database synchronization framework will no longer exist…