Monday, April 5, 2010
I am only comparing high end City and Linea Diesel as this was my comparison criteria.
Price
====
I am taking price as the first comparison, cause that also will have big impact on your decision.
Below x-show room price,
Linea Diesel Emotion Pk – 8,47,000/-
Honda City Vxi MT – 9,27,000/-
1. Steering Wheel
i. Look :- Both are comparable and I don’t give much weightage to either. However Blue and Me panel in Linea gives a more sophisticated look. Mounted buttons are great since phone also integrated in linea.
ii. Comfort. Honda City is far better, thanks to EPS. Believe me, its just superb in low speed as hydraulic PS is no way near to this comfort. You feel like using only a finger to handle it. If you are planning to drive yourself most of the time, this is a major factor to consider.
iii. Tilting. Honda City is superb. You can place in any angle and the liver is so smooth. On the other hand Linea has only two positions and liver is difficult to handle. Linea is the looser here.
2. Gear
i. Comfort. Honda city Gear shift felt more smooth compared to Linea. However the City I drove has done already 19k Kms and Linea was just 400 Kms. So I just say both are fine, but many articles says Honda City is better. It is not a major point to consider as the difference is trivial.
ii. Look. On par.
3. Speedo Meter and Panel
i. Linea scores high. It gives a classy look. Also the calendar display in the from panel is eye catching.
ii. Information related to the vehicle supported in both the cars are on par. However My Car is a great feature rich common display panel in Linea. Linea scores high.
4. Accelerator, Clutch and Break.
i. It was a surprise to see that Linea’s clutch was silky smooth compared to City. City being petrol I expected other way round. I think city I drove was not serviced for some time. Clutch smoothness is really important for any long drive hence it was very important for me. However I don’t make call here, instead would say even though Linea is diesel, its clutch is smooth. No specific comments on Accelerator and Break.
ii. Break System. Both are ABS with EBD. Both I drove around @120-130km and applied the break. Both responded well and good control. However I am not that expert comment on minor differences if it has. Also Honda city claims Power Assist, which I didn’t see in the spec of Linea. But the city guys itself said Power assist is required for EBD to work.
5. Music System, Dash board Panel
i. Music System. I couldn't really compare the music system performance. I planned to check the system by playing the same music from my Ipod. However I didn’t take my USB cable along with. But the many articles suggest both are on Par and City performing well in high volume.
ii. Look. Look of this panel is far better in Linea as it has My Car extra. The buttons and color combination in Linea looked better for me. However overall standard/quality of buttons looked cheaper to me compared to City.
iii. Here there are lot of feature difference between Honda City and Linea. My Car, Automatic climate control, Outside Temperature info etc. Big difference is the automatic climate control, which is great and only available in even higher ranges. Linea scores very high.
6. AC
i. Honda city AC is very standard like other good cars. Linea claims to have automatic control. The temperature set in the car I drove as 16 degree. However it never reach 16 and was always working for 30kms I drove (I guess the actual temp would have been 20+). Back vents are specific to Linea and may be good in long drive when fully packed.
7. Mirrors.
i. Side mirror in Linea is electric controlled. Even the left mirror can be controlled by sitting in the drivers seat. I found this very useful and a good point to Linea. However the controlling buttons looks to be very cheap.
ii. Rear view mirror is day and night, which is standard in any good car. So no comments.
8. Other Features : Linea supports Blue & Me which is very unique even though it is from Microsoft. It has speech recognition mechanism and you could dial by telling the number/contact name. However you need to pair your mobile phone each time you start the car (there should be some way to avoid this). Speedo meter takes multiple values like, range/avg speed/inst consumption/avg consumption/travel time. Linea scores very high.
Linea has remote boot open using the key. HC has petrol tank remote open in key. Both car has immobilizer, a great feature to have.
9. Engine :- HC engine is well proved i-vtec and very durable. Linea diesel engine is the world wide supplied one and very well proved. Maintenance intervals are very less in Linea (15K KMs) vs 5K interval for HC. Engine noise is almost nil in HC, but diesel engine makes its presence very clear when driving especially 2000 RPM or more. HC scores high.
i. Power : - No comparison, petrol zooms faster. 115 HP vs 86 of Linea. However torque is more in linea, means it pull harder. If you looking for reaching 100 km/h 5 seconds faster HC scores higher. If you don’t mind that, you can give equal weightage. You don’t have to bother whether Linea can take you to a steep hill.
10. Inside space :- Linea is longer and heavier. Space inside looks to be same. However while sitting on the seat of HC with max height was almost touching the roof. There may be 1-2 cms difference here I guess. Not a real concern.
11. Seats :- Is on par. However the sitting comfort on the seat is better in HC. It looks to be more wider and soft. Linea has very hard seat. HC scores better.
12. Fog lamp :- Linea comes with front and back fog lamps. HC has only front fog lamp. Back glass of linea comes with a heater defogger with timer (20 mins), not sure about HC.
13. Service :- Fiat Marketing/sales team was not as professional as Honda. I had 3 test drive on Linea and two on HC. Fiat doesn’t even followed it up with me, however HC team called up twice to see any assistance was required. Even a request for test drive in Fiat website was not answered, nor the sales team of Tata dealership. After fixing a date and time for test drive of Linea no one shown up.
Summary
If you are a techie looking for lots of features without compromising on look and comfort go for Linea. If you are sporty and wants higher power and zoom on highways, HC is better option.
Both cars easily reaches 120 KMs without much effort on high ways and are very steady. As per many analysis Linea has slightly better control in high speed.
If you would consider price as another parameter Linea saves you almost 80k with less maintenance cost.
Service could be a problem with Linea as it is evident from the marketing team of both cars. HC team is thorough professional and you can expect the same after sales, however TATA/Fiat has to the prove it.
Please send your comments feedback.
Thursday, February 5, 2009
Feature Processing Framework
Have you ever wondered how much time is spend on repeated changes in module. You, your team and testing teams spend considerable amount of time in making sure existing code base is not broken. At the end, your client is not happy with the turn around time and quality. All the time and good work you and your team spend is not been appreciated. Have you ever felt this? Even other wise what about saving considerable effort in providing new solutions in your existing product ?. I will explain some interesting technical solution which can be applied if you are working in a product company. If you are working on a product or going to develop one, and you expects lots of churn in future below explained technique will help.
Let's take an example of efforts required on a medium churn feature change request from field on an existing product.

If you closely analysis this data and from your experience you can make out that ~3-3.5 WK will be spent on making sure existing code is intact and none of the functionality is broken. That is around 30% of total schedule. How do we save this time or reduce to minimum? First thing comes to your mind will be to, separate the base functionality and feature to different planes. Yes that is what I am trying to explain further, how to achieve that. Feature Processing Environment(FPE) is discussed in details, so read on.
Feature Processing Environment is a different processing environment from the the base application where all the features are getting added. Provide a mechanism from base application code to give a generic call to this environment. Each feature is executed independently in this environment and result is send back to the application code in a pre-defined protocol. Base application code defines pre-defined events from where trigger to FPE is invoked. Once the event notification is received in FPE environment each feature registered for that event will get a chance to look into it and take action if interested. (So you guessed now, that FPE is following Chain Of Responsibility patten). Let us jump into high level diagrams to get inside of it.
FPE Communication Diagrams

FPE Class Diagram

Lets examine the important classes and its responsibilities.
BaseApplTriggerPt1 and BaseApplTriggerPt2 :- These are the application base level trigger from where FPE can be entered.
EventFeatureController :- This is an optional class needs only if required. In this implementation the responsibility of this class is to mould FPEInOutData which is the protocol between FPE and application base. This class also can be used for taking any intermediate action before and after entering the FPE if required.
FeatureProcessor :- This class is the core of the FPE framework and is a singleton pattern. This class holds all the registered feature objects. All the events are notified to this class and in turn invokes the registered feature objects and thus by giving each feature object to take action if it is interested.
FeatureObjectFactory :- This class is responsible for creating all the FPE objects and initialize the objects. During this initialization procedure all the FPE object shall register with FeatureProcessor with interested events.
Feature 1,2,3 :- are the features in this example which has implementation for specific feature.
FPEAction Pool :- This class is optional. In this example this is a flyweight pool where action objects are stored. FPE Feature Object can request for any action objects from this pool and take generic actions.
FPEInOutData :- Is the data structure which is the core of protocol. FPE and base application communicates using this data structure. Only the base application code and FPE Feature Objects understands this structure and all other classes should be unaware of this structure to make sure the FPE frame work is generic.
Registration of FPE Feature Objects and invocation.
During application initialization FeatureObjectFactory creates all the feature objects and initializes using initialize method. Each feature object is aware of the events it is interested in and registers for those events with FeatureProcessor. When application bases passes the events to Feature Processor, this register is used for invoking interested features. This way any new feature addition doesn't need any change in base application code. New feature can be added in FPE without touching the base code.
Let us check again how much effort we saved by using this framework.

We are able to save ~25% with this effort. If you analyse closely, we couldn't save any thing from sanity+system test. This is mainly due to the reason that system test team doesn't believe in the way low level design is organized. Since entire application is rebuild, they have to do the basic sanity + system test. Also the build and packaging effort is still same even with this design. The solution to this problem is adding feature objects dynamically. Means, base code is always same and add feature objects dynamically which can be added and removed run time without providing any new load. Seems interesting... ? Then read on..
Let us enhance our static FPE Object frame work to dynamic FPE object frame work.
To achieve this, we need to depend on some of the OS functions to load, shared objects dynamically. I am using Linux OS, so other OS freaks should check your OS manual for similar functions.
The static'ness' of the FPE is due to FeatureObjectFactory which is hard coded way of creating all FPE objects. So obviously we need to re-work on this class to achieve dynamism. In order to load features dynamically all the features needs to be packaged as separate .so object or group in a .so object library. Call dlopen function to load these .so objects and dlsym to invoke the entry procedure. This will invoke the entry procedure defined in the .so object library. From this entry procedure create the FPE object and register it back to FeatureProcessor. So how do we know the absolute name of the of .so library?
We need to have a dat file (.dat/xml/.txt) where all the names of the shared library names are defined. Introduce a new builder object in FPE frame work to open this dat file and load all .so libraries dynamically. All the library entry procedure names needs to be a common one. In my example code I am using the name as featureEntryProc.
Let's examine the modified class diagram (only important classes are shown).

Main of your program creates and initializes the builder class which in turn parses the XML file and gets the absolute name of the shared objects (.so lib). Using the dynamic loading functions, builder invokes the entry procs in these shared library which in turn creates the FPE objects and register it back to FeatureProcessor. This way for adding any new Feature into your product, all you have to do is to create your own .so having the feature implementation and make an entry in XML file. You need to supply just this .so library and XML file to the field for new feature functionality to be supported in your product.
We are there. Let's get back the sanity effort from Sanity + System Test.

Note:- Note that even though this looks to be straight forward, implementation will have different problems to solve. For example if you are adding FPE into your already existing product, the protocol between base application and FPE needs to be worked with lot of thought. FPE responses shall be very generic and covering all the cases to make sure to avoid rebuild of base product. Another area you need to be careful is where inOutData is passed. FPE should get all the data it is looking from the base application and should have place holders for response. Another point requires thinking is the trigger points from where FPE can be entered.
Check the C++ code sample below to get the complete picture.
http://docs.google.com/Doc?id=ddcxq998_1gx7tcscg&hl=en
Conclusion :- FPE is an efficient way of adding new features dynamically which saves lots of effort in all the states of software life cycle. It not only saves effort but will enable you to deliver features with less turn around time. Since no new build is provided customer's comfort will be high. However, core of the FPE is the framework. Considerable thought and effort should be applied while making the framework to make sure it is generic enough and works in most of the cases.