While commuting to office, I noticed that Wipro is developing software factory model which will improve their delivery model. This made to think how well a factory model will fit in software development where human skill makes the difference. This is an experimental model based on Toyota Manufacturing Model.

Software factory is all about about assembling components (or plugins) to incrementaly build the application. This suits good for a product development platform.

How Wipro can leverage this for the services they offer? My guess is

1. Wipro is not building the components which will help in assembling.

2. Wipro’s process maturity will ensure the quality of product. The vast knowledge of Wipro’s large talent pool has to be documented, developed as a process to apply them in their delivery model

3. Any average engineer by following the processes rigidly can ensure the consistent quality.

How this will impact the people

1. Organizations with robust factory model need not always recruit the best guy and pay more. Any average guy who follows the process will be sufficient.

2. Opens the gate for average people and keeps the attrition in check. People skill will become commodity and might be referred as as Software Assembler

3. Engineers who build the components for assembling and who document the knowledge base and converts them as the software process will be in great demand.

As usual Wipro has shown great business acumen in adopting this approach. We need to wait and watch how this fits in Wipro’s delivery model.

Though the developers consider commercial platform while developing the application, the knowledge of the environment is minimal as the operations take care the bulk of the activities. When I say the knowledge is minimal, it is more on how the different applications co-exist in the commercial platform than how they are integrated at the lower level especially at the network layer. Though the developers need not worry about them, they will run into trouble when there is an integration issue.

Since the application has passed through different phases (like test, beta), the chance of application issue is remote (though cannot be written off). Most likely reasons can be network configurations, firewall rules, NAT entries etc. These can be identified only with a good understanding of the commercial platform. 

This knowledge becomes critical when you are a non computer science graduate ventured into software development. Pick some books on network basics, routing rules and understand your commercial platform with the help of operations team. 

Rediff has published an excellent article on Team Leadership. This article is an excerpt of the book ‘ What Type Of Leader Are You? by Ginger Lapid-Bogda‘. The essentials of the leadership are given excellently and the following are listed in the article.

• Provide Team Leadership
• Create a team vision
• Attract and develop Team Talent
• Design a Team Architecture
• Establish Effective Team Processes
• Build a Team Culture
• Assure Quality products and services

These competencies are identified carefully and this covers all spheres of leadership. If a leader plans the activities to ensure his tasks falls under these list, he can grow as a excellent leader. This is one of the checklist I am using now to plan my activities to ensure that I do not fall under the category of bad leaders

Look at this link if you want to understand the JBOSS Architecture. Initially I was under impression that JMX is used only for management and monitoring. But the JBOSS architecture shows how powerful is JMX and how it can be used to enhance modularity in your applications.

Though there are lots of estimation models available for software development processes, I use the following easy (basic) approach to do a quick estimate.

1. Break down the requirements into tasks and sub tasks.

2. A small defect or enhancement will be a task and can be broken down as sub-tasks.

3. For every task/sub-task, do an optimistic estimate for design, coding, unit testing, integration testing etc based on the team’s average productivity.

4. Based on the team’s productivity, adjust this factor. Remember that the estimate we get for the first time is always optimistic and the work cannot be completed by that time due to unplanned activities cropping up.

If your team is good and experienced, you can increase the estimate to the maximum of 50%. This 50% increase is required to take care of design documentation, integration testing etc. Most of the developers when asked for estimation will skip this part and give estimate only for coding.

If the team is new and less experienced, you can increase the optimistic estimate by 75% to 125%. This increase is required to ramp them up along with the time required for tasks mentioned above.

Always remember, more the number of sub tasks, better the estimation quality.

Very good article…. read till the end.

Knowledge@Wharton has published a excellent analysis on perks available at Google office. Though they are all business, it makes a very big difference for the companies which offer those perks. These perks improves the company branding which in turn helps to attract the best talent to the company. Infosys is one of the Indian IT services major does right in branding their development centers, perks like mini-golf course, gym, food courts etc. But it needs vision and correct branding of these perks to achieve the else these will look like a shameless way to make the employees work late.

In my earlier post, I discussed about how the configurations can be managed in an enterprise application easily. This is an exclusive post to discuss about the configuration management best practices based on my experience.

1. Put comments for every configuration parameters. This applies for configurations as it applies for code. The operations team who will manage it cannot understand it without comments. Also if new instance is setup, you may not be involved and comments will help operations to decide the new value.

2. Where ever possible, put the example values in comments and how the application will be behave if the value is changed

3. If the configuration file is shared with other components, maintain a copy of parameters used by your application. This will help you if you want to maintain the configurations separately.

4. Though java properties files are good, to maintain large configuration information, I prefer Windows INI format for its grouping. Let the configuration readers return the values in java properties format.

5. Have a singleton configuration loader to manage the configurations. Application will always get the value from configuration loader and NOT cache it locally

6. Implement JMX console to refresh configuration values in singleton loaders so that application need not be restarted.

7. You can also put a monitor to load configurations if the file is modified. This will avoid the server restart to apply the new configuration values.

8. The last but the most important one – NEVER modify your configuration file without taking a backup. If the file gets messed up and without backup, your service will be severely impacted and you cannot meet your SLA.

Effective Java Programming Language Guide by Joshua Bloch is one of the book I always recommend to java users who want to write the best java code. After reading the book, you can find big difference in the way you think and write java code.

A must read book for every java programmer.

This is the second part of my earlier post JVM – GC Tuning

Let us start our JVM heap tuning by identifying the factors which influences the memory management

1. Number of CPUs in the box

2. Max heap size available

3. Object creation rate in the application

4. How long the objects will be required

5. Average session time

6. Tradeoff between GC and Performance

Tradeoff between GC and Performance is very critical and if you tune for one, the other will get impacted. Keeping both of them within the acceptable limit is the key while tuning JVM.

What are we looking for in the application? Is it performance improvement or stability improvement?

If improving performance is the objective
Heap Tuning – Move the objects very quickly to the older generation. Keep young generation free for new objects.

GC Tuning – Ensure objects are collected quickly in young generation. If it is not collected, move to old generation immediately. Young generation should be kept free as much as possible for high performance applications else while processing, JVM will wait for GC to free up young generation.

If improving stability is the objective
Heap Tuning – Ensure only required objects are moved to old generation.

GC Tuning – Ensure objects are collected quickly and not moved to other spaces unnecessarily

So now what are the minimal parameters required

1. Max and min heap size

2. Young generation space – Within heap, what is the young generation size

3. Survivor ratio – Ratio of the Eden/survivor space size. Young generation is divided into Eden and 2 survivor spaces. Both the survivor spaces have the same size.

3. Max threshold value – How many minor GC the object can survive before moved to old generation

4. GC algorithms

GC and Heap tuning will be challenging when the max heap size available in small. Let us take a hypothetical case of web application where stability is the primary requirement and max heap memory available is only 256 MB. The application was developed long back and developers did not worry about the memory constraints and now due increased usage, application encounters out of memory. Most of the developers would have encountered such applications in their career.

How we can apply the above parameters for this scenario.

1. Max and min heap size – 256 MB. Not much option here. Max available is 256 MB only.

2. Young generation space – Stability will be impacted when too many objects are moved to old generation very quickly and if they cannot be collected quickly. So we need to ensure we have big young generation. Let us go for 128 MB.

3. Survivor ratio – Objects are first created in eden, then moved to survivor spaces before they are moved to old or tenured space. Let us maximize the survivor space by opting for value 2. With this setting, eden size will be 64 MB and each survivor space will be 32 MB. (In case of high performance applications, survivor space will set as 20000 so that the size of survivor space will be minimal and objects will be promoted to old generation quickly.

3. Max threshold value – Since our survivor space is big, let us keep this value as 10. The default is around 30.

4. GC algorithms – Opt for new generational parallel GC and concurrent mark-sweep collector. Classical concurrent collector will for 68% of space to get filled up before running full GC. Since we have limited old generation space, include incremental collector so that as and when objects are available it will be collected. These GC algorithms are selected based on heap size. If the heap size is large (few gigs), then throughput collectors are more efficient than this.

The values I showed above are very aggressive to improve the stability. As we all know these values cannot be applied directly without a detailed study of factors, which will influence the memory management in JVM.