• You are the owner of a start-up company:
• • Even you are a technical expert, the cost to bringing up the strong development team is so high. At the beginning, you and your team has to be market focused. Talking to prospects, directors, investors and composing business plans, product road-map may take you a lot of time. Not spending enough time to build strong development team causes a lot headache later: you lost money, your software has bad quality and need unacceptable (for a start-up) cost to repair, your customers are not satisfied.
• It is very difficult to recruit good resources in your city:
• • Your city has only 15.000 residents, you post the jobs to dice to recruit a senior Java developer who has experienced of jackrabbit but you can not find him. Lack of local resources prevent you ramp your team up as plan, that makes your delivery schedule is late. You should engage with a outsourcing agency as soon as possible, who has resources on pool or can hire skilled engineers easier.
• Needs of using resources temporarily:
• • You simply want to have a software with set of features, very few minors are added after completing development. If you hire 10 developers for one year, after that you only keep one developer maintain your product. Probably you are at risk, the unique developer could move your team when he want to move to other job. All bad codes could not be maintainable by others, you ask the help from outsourcing agency, but it is too late.
• Your team has no resource for specific skills:
• • You have two PHP developers and three .NET developers. And you need to develop a Rich Internet Application using Flex and PHP. Instead of spending training cost Flex to your developers, take development risks while you do not have enough experienced developers for you crucial project, hiring some Flex developers from external party to work with your internal team members is a good choice to insure your project will be developed successfully.
• Focus to core business:
• • Your company must maintain core and non-core functions but lacking resources. By outsourcing non-core functions, your employees can be put to better use and you will be able to see a huge growth in your core business.
• Advantages of different timezones:
• • The uncompleted works of your employees could be handled by outsourcing partner. This is extremely helpful for 24/24 service such as system maintenance, call centers.
• Saving cost:
• • Salary of Vietnamese developer is much lower than US developer. Engaging professional and high productivity Vietnam software company is a good option to reduce costs of your company: development, administrator, training, salary and other expense costs.
• Utilizing solutions of partners:
• • Your company needs a groupware software to collaborate associates in company. Instead of spending much effort of your development members to develop various modules like chat, email, forum, document management etc you can seek many free and/or open source groupwares. If you need some specific requests that current groupwares can not serve, some companies provide professional services to fulfill your needs.

In our application, we use Spring as IoC container, though set up the Ehcache manager is the easy task but we would like to use it with our Spring beans and exposed it as Osgi service. Spring modules is the good library help us easy in configuration. It provides the consistent abstraction caching to our application, hence we can use our cache facade with other caching libraries such as JBoss cache, JCS, OScache without chaging our application code. You could download the Spring Modules at https://springmodules.dev.java.net/.

Here are the following steps to configure Ehcache in Spring application

Configuring caching via ehcache.xml file

<?xml version="1.0" encoding="UTF-8"?>

<ehcache xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:noNamespaceSchemaLocation="ehcache.xsd">

 <!--
 Configure it if you have overflowToDisk or diskPersistent enabled for any cache.
 java.io.tmpdir - Default temp file path
 -->
 <diskStore path="java.io.tmpdir" />

 <!--

    Mandatory Default Cache configuration. These settings will be applied to caches
    created programmtically using CacheManager.add(String cacheName).

    The defaultCache has an implicit name "default" which is a reserved cache name.
    -->
 <defaultCache maxElementsInMemory="10000" eternal="false"
  timeToIdleSeconds="120" timeToLiveSeconds="120" overflowToDisk="true"
  diskSpoolBufferSizeMB="30" maxElementsOnDisk="10000000"
  diskPersistent="false" diskExpiryThreadIntervalSeconds="120"
  memoryStoreEvictionPolicy="LRU" />

 <!--

    Sample cache named sampleCache1
    This cache contains a maximum in memory of 10000 elements, and will expire
    an element if it is idle for more than 5 minutes and lives for more than
    10 minutes.

    If there are more than 10000 elements it will overflow to the
    disk cache, which in this configuration will go to wherever java.io.tmp is
    defined on your system. On a standard Linux system this will be /tmp"

 -->
 <cache name="engroupCache" maxElementsInMemory="10000"
  maxElementsOnDisk="10000000" eternal="false" overflowToDisk="true"
  diskSpoolBufferSizeMB="20" timeToIdleSeconds="300"
  timeToLiveSeconds="600" memoryStoreEvictionPolicy="LFU" />
</ehcache>

Declarating Ehcache in Spring context

<bean id="cacheManager"
 class="org.springframework.cache.ehcache.EhCacheManagerFactoryBean">
 <property name="configLocation">
  <value>classpath:ehcache.xml</value>
 </property>
</bean>
</pre>
<pre lang="xml" xml:space="preserve" xml:lang="xml">
<bean id="cacheProviderFacade"
 class="org.springmodules.cache.provider.ehcache.EhCacheFacade">
 <property name="cacheManager" ref="cacheManager" />
</bean>

Programmatic use

Using ehcache is so simple, a unit test to make the test whether configuration is set up correctly and take the simple put/get could explain all.

@RunWith(EngroupClassRunner.class)
@ContextConfiguration(locations = { "/META-INF/spring/cache-context.xml" })
public class CacheTest {
    @Autowired
    protected CacheProviderFacade cacheProviderFacade;

    @Test
    public void testCacheConfiguration() {
        Assert.assertNotNull(cacheProviderFacade);

        EhCacheCachingModel model = new EhCacheCachingModel();
        model.setCacheName("engroupCache");

        cacheProviderFacade.putInCache("a", model, new Integer(1));
        Integer fromCache = (Integer) cacheProviderFacade.getFromCache("a",
                model);
        Assert.assertEquals(new Integer(1), fromCache);
    }
}

Besides of using ehcache to create the session like variable in our application, we would like to use ehcache to cache SQL statement in iBatis and integrate with Terracotta to complete our distributing caching solution in our future project. I will keep the post on further caching usage in future posts. Keep reading!

• Write the simple test first, then write code. After that write test code for more complexity functionality
• Keep test code as simple as possible
• Run test immediately whenever complete writing code
• If spending much time for writing code, break the functionality into smaller ones and applying TDD for these pieces
• Whenever test code or productive code smells, refactor it immediately
• After writing code, use coverage tool to make sure productive code is covered 100% by test method. If some piece of code is not covered, your implementation has issue!
• Use mock objects if needed
• Automate unit test and intergrate them into CI server

Technorati : TDD, software, unit test
Del.icio.us : TDD, software, unit test
Ice Rocket : TDD, software, unit test
Flickr : TDD, software, unit test
Zooomr : TDD, software, unit test
Buzznet : TDD, software, unit test
Riya : TDD, software, unit test
43 Things : TDD, software, unit test

There are several models-processes for quality management in software industry such as CMM, CMMI, TQM, ISO. However, software industry is different with manufractoring industry. In manufactoring industry, to measure the quality of service is rather simple: the assessment can be based on the number of products fail compare with its specification. In software industry, the factors to make the product fail is many:

• Number of defects.
• Quality of architecture, component and source code.
• Cost of development
• Effort of external support etc

Because software is delivered to specific group of users, the list of factors to assess the project success are different among projects. To some clients, they only assess the quality of product base on the number of defects. Others can assess the quality of product base on many criteria such as source code quality, effort to support development. The Quality Management Program is the program of one organization and above events do not mean organization will manage the quality services base on the client needs only (what happens when they change their criteria in future). So the organization must has its own criteria to assess the service they deliver.

In fact, the relationship among cost - architecture - productivity in software industry is very closed. If application has a good architecture, it can lead saving effort of development that means the productivity is increased also the quality is better. By having more productivity, that means you will save development cost. The benefit is clear enough, however how to increase the productivity of an organization is a big challenge. My proposals to improve the quality falls in the following categories:

• Recruitment process
• Training plan and execution
• Software Development Process
• Project Management
• Technical and Quality management
• Knowledge management

In fact, identifying the organization's problems is the difficult task but it is harder if you propose solutions that can work. The solution does not come not only from research yourself but the organizational behavior must be included. I have read the suggestion that how the organization can improve on specific problem and it is theoretic. It is not hard to read books and exceprt the others' experience and force others follow that, after that say that we can not apply because I am right and you are wrong or they are done successfully in practice. In order to make the change impacts to organization, the following factors must be considered:

• The executive team must lead Quality Improvement Program.
• The culture of organization.
• As TQM principle, all members must be responsibility of Quality management and continuous quality improvement program.
• The program should be divided into short phases (2-3 months at much) for assessment.
• The goals and achievements must be measurable and practical.

According to Nayantara Padhi (http://software.isixsigma.com/library/content/c021230a.asp), the eight key elements must be considered while implementing the Quality Management Program:

1. Ethics
2. Integrity
3. Trust
4. Training
5. Teamwork
6. Leadership
7. Recognition
8. Communication.

These key elements are divided into 4 groups:

1. Foundation - It includes: Ethics, Integrity and Trust.
2. Building Bricks - It includes: Training, Teamwork and Leadership.
3. Binding Mortar - It includes: Communication.
4. Roof - It includes: Recognition.

I will keep the post of managing quality of each above functional area in future besides more posts focus on Portal, Spring, Osgi, php and java scripting language that I am focusing recently.

1. Choose some common tools and framework and assign members to learn that with hope that client will request use it in future.
2. Developing API library for common functionalities like security, parse text etc with hope that this library can be used in future.

If you are working in software industry, you may already know these solutions also you know the benefits of choosing these solutions: having the expert for some framework, tools that can be used in future also reduce the development cost by re-using the existing proven code. But in fact, these approaches also have the following limitations:

1. There are many well-know tools and frameworks that serve for the same purposes, for example there are some couples Hibernate-iBatis (ORM), Spring-Pico (DI container), Spring-AspectJ (AOP), Ehcache-OSCache (caching), JSF RI - My faces (JSF framework), Tomahawk - Trinidad (JSF components), Facelets - Tiles (Web template), Wicket - Spring MVC - Seam (MVC web framework) etc. Choosing the appropriate tools to spend effort for research is not an easier task also we do not make sure client will use these tools, if they do not the company will lost money for researching without any re-payment.
2. Common library that is developed without concern on context also lack of knowledge of API design can cause the effort of development is useless and this work can not be re-used in project.

Moreover, lacking knowledge of tools are planned to use in project can cause the cost of project can not be estimated soon. If some project needs the many open sources or standard web frameworks as Ant, Spring, Hibernate, Java Server Faces, Spring MVC, Facelets etc I am sure that team will spend a lot effort of set up the working environment also integrate for all works well together. I have spent 6 days for configuration only for the tools and framework Spring, Hibernate, Maven, JSF, Facelets, Osgi and Spring-JSF also I faced many problems of solving the version issue among JSF-RI, My faces and Apache ADF framework. I must spend a lot of time for reading books, articles, blogs also some hints on Internet to solve integration problems among these frameworks. It is hard to combine such tools of packaging. If my client's needs me provide solution within 5 days, I will fail the project!

Continue above statements, you must to choose the solution within the strict timeline and send the estimation for project, if you are not sure about your solutions the cost you propose will be high and you will fail to get project, if the cost is low you will face another problem that the development cost can not be controlled well because your team will spend time for fixing integration problems of third-party, handle the problems cause by tools etc and your team will lack time for implement product's functionalities. In web design, we have web template that provides designer the framework to build the website faster and no mistake, there are many web templates that fulfill the user's requirements and use web template is extremely useful while building a website but I see no similar thing in software development. In fact, almost products have the following components and/or optional requirements:

1. Login module.
2. Password reminder (web application).
3. Security mechanism with roles support.
4. Logging module.
5. Caching.
6. Unit test.
7. Design base on 3-tier pattern: UI - Controller - Data access layer.
8. Tracking performance.

The template project is the scheme that integrate all tools and frameworks into one workable place for the specific type of application. One example of template project is App Fuse. Let's read the following description of AppFuse project at AppFuse website

AppFuse is an application for "kickstarting" webapp development. Download, extract and execute ant new to instantly be up and running with a kick-ass Java webapp running on Tomcat/MySQL. Uses Ant, XDoclet, Spring, Hibernate (or iBATIS), JUnit, jMock, StrutsTestCase, Canoo's WebTest, Struts Menu, Display Tag Library, OSCache, JSTL and Struts (Spring MVC, WebWork, Tapestry and JSF are also options). To learn more about AppFuse, its history, goals and future, checkout AppFuse: Start Your J2EE Web Apps on java.net.

By using AppFuse, you can perform the common functionalities of one web application while you take less time of integrate such complete tools and frameworks work together. And you only need develop some talent guy to expert the template project for each kind of project not distribute effort to various tools and frameworks as the solution 1,2 I have described above. Instead of spending time for many tools and frameworks in separated way, try to combine them in one and spend your organization effort into one solution only. By choosing the template project for each type of project such as Java standalone application (Swing, Hibernate, Spring etc), Java web application (AppFuse) etc, the organization will reduce the research effort that you can advise the client they should choose a template project that meet's their needs about technology. To cover all kinds of projects, we have only the limited number of project template. They will help you increase the quality of project also reduce the effort of development. Sounds great? I will do so!

Many project managers tend to think a successful project must meet only the following criteria:

• All features are implemented.
• The quality rate meets is lower than upper constraint limit.
• All documents meets client's request.
• All non-functional requirements meet the client's request.

All above criteria is good but it is not enough. The quality rate is low when team deliver does not mean the product has high quality. One important thing the project/product manager must focus on, it is the quality of product that falls into two categories:

• Quality on functionality:
  The quality of functionality is showed by number of defects in tracker, phone that user call for support, complaints of user to forum, web site etc.
• Quality on source code/architecture:
  The bad quality of source code can cause the bad quality of functionality. However in case product has high quality on functionality, the quality of source code/architecture is bad. That leads the effort for operation. maintenance high or even very high. Modify a little functional requirement that cause a lot of modification and testing is a signal that product has no quality and it is not acceptable.

By losing the product's quality, the cost for operation and maintenance can be high than expected. In some cases, the company would like to build another product that is lower cost and more maintainable than the old one, and the life cycle Have one - Bad quality - Have new one started

Project/Product manager tends to focus on quality rate in specific time (not entirely quality of functionality) and they rarely focus the quality of source code/architecture. Though TA is responsible on quality of source code/architecture but PM has the right of assignment. PM try to urge development implement as much features as possible, the reason is they are not confident on product quality and they would like to have more buffer time to correct mistake if any. Developers and QC, under the pressure of PM, try to implement and cost as soon as possible. After that the code is mess, the quality is low. After that, QC try to find all possible defects and developer try to fix all. But low quality in source code/architecture can cause fix is a mend, one fix defect can cause one or more defects. Team try to work overtime and fix defects until defect rate is lower constraint. Many complaints will be raised during development such as hard client, complex project or estimate is wrong but the root cause is team that does not control product's quality well and schedule for development is not appropriated that lead the team's productivity is low.

So, pay enough focus on product quality on both functionality and architecture will decrease the cost of development, operation and maintenance. Project manager should make all members are aware that. Implement a feature faster than schedule in many cases not good for product's quality and it can be a signal that PM is not confident on team, however some see it as the best practice while team is lazy and press schedule will force them run faster. Make enough pressure to team and notify them care about the product's quality is a preferred way that decrease the cost of project.

Say in other words, project's scope is what client needs in their product and it is a must for them in almost cases. It is great if you provide the product on time with high quality that fulfill all requirements defined in project's scope and plus some additional features outside project's scope (that is treated as a gift to client). However, when development team can not do that, they must implement things are defined in project's scope first with no objective. In practice, when choosing solution, almost team would like to choose the best solution to solve problem; many cases, the best solution can cause the conflict with timeline, resources and provider to client over what they needs. Development team tend to think client will be aware with their effort, their dedication also the solution is better for client's business. But we can not be sure whether this solution is better for customer's business without asking them (if you think it is better, please providing your suggestion, if client agrees the project's scope will be changed and schedule/resource can be changed also) and implement without any concern about timeline and quality. "The more you do, the more mistake cause by yours", team do much but client does not appreciate what they do while team expect the client satisfy their performance!

So while you choose any solution, team should consider the timeline and especially project's scope. Whenever, you complete the project's scope within timeline, it is time for you to consider provide gifts to client by improving the quality but you should limit adding additional features if needed. Not think that client will be aware your performance while you provide them the product is different project's scope, it has more functionalities but more defects also it is delivered late than schedule.

• Intent: describe the goal of pattern and reason to use it.
• Motivation: provides the scenario consisting of a problem and providing the context that pattern can solve.
• Consequences: the side effects cause by this pattern.

Mostly, this problem is applied for both novice designer who is dizzy with what pattern does also 'experienced' designer who apply patterns base on their previous projects. I can say some common practices:

1. If client request support multiple databases --> DAO pattern. If they don't why do we need apply that.
2. For one instance has global scope --> use singleton pattern. See this for some comments on singleton pattern.
3. Undo/redo use command pattern.
4. Validation or pre-processing use Chain of responsibility pattern
5. etc

Some is correct for almost contexts of problem but it is not true for whole cases. For example, if you know what the system only support one database, do you need to apply DAO pattern. I see one case when designer can not answer the questions from client that why they apply DAO pattern in case only one database is served for system. It is because he did not know the motivation of DAO pattern (what the bad of some stupid books J2EE design pattern when it describe DAO because it hides the main idea of Factory pattern in GoF and makes people think the main purpose of DAO pattern is served to multiple databases).

I have read this jokes about applying wrong pattern and it is actually true, you should think that applying pattern is not the ideal solution except use it correctly. If you can not, it can cause harm to you work. Note that the original article is gotten from http://www.lsd.ic.unicamp.br/~oliva/fun/prog/resign-patterns but I would like to copy here in case this link is invalid in future (I have some bad practices when I add some favorite link but later I loss such knowledge in case these links are not longer existed).

Resign Patterns
Ailments of Unsuitable Project-Disoriented Software
by
Michael Duell
mitework@yercompany.com

Abstract

Anyone familiar with the book of patterns by the Gang of Four [1]
knows that the patterns presented in the book represent elegant
solutions that have evolved over time. Unfortunately, extracting these
patterns from legacy code is impossible, because nobody knew that they
were supposed to be using these patterns when they wrote the legacy
code. Hence, this work is a catalog of patterns for the masses. The
patterns presented here represent abundant solutions that have endured
over time. Enjoy reading the patterns, but please don't use them!

1 Cremational Patterns

Below is a list of five cremational patterns.

1.1 Abject Poverty

The Abject Poverty Pattern is evident in software that is so difficult
to test and maintain that doing so results in massive budget overruns.

1.2 Blinder

The Blinder Pattern is an expedient solution to a problem without
regard for future changes in requirements. It is unclear as to whether
the Blinder is named for the blinders worn by the software designer
during the coding phase, or the desire to gouge his eyes out during
the maintenance phase.

1.3 Fallacy Method

The Fallacy method is evident in handling corner cases. The logic
looks correct, but if anyone actually bothers to test it, or if a
corner case occurs, the Fallacy of the logic will become known.

1.4 ProtoTry

The ProtoTry Pattern is a quick and dirty attempt to develop a working
model of software. The original intent is to rewrite the ProtoTry,
using lessons learned, but schedules never permit. The ProtoTry is
also known as legacy code.

1.5 Simpleton

The Simpleton Pattern is an extremely complex pattern used for the
most trivial of tasks. The Simpleton is an accurate indicator of the
skill level of its creator.

2 Destructural Patterns

Below is a list of seven destructural patterns.

2.1 Adopter

The Adopter Pattern provides a home for orphaned functions. The result
is a large family of functions that don't look anything alike, whose
only relation to one another is through the Adopter.

2.2 Brig

The Brig Pattern is a container class for bad software. Also known as
module.

2.3 Compromise

The Compromise Pattern is used to balance the forces of schedule vs.
quality. The result is software of inferior quality that is still
late.

2.4 Detonator

The Detonator is extremely common, but often undetected. A common
example is the calculations based on a 2 digit year field. This bomb
is out there, and waiting to explode!

2.5 Fromage

The Fromage Pattern is often full of holes. Fromage consists of cheesy
little software tricks that make portability impossible. The older
this pattern gets, the riper it smells.

2.6 Flypaper

The Flypaper Pattern is written by one designer and maintained by
another. The designer maintaining the Flypaper Pattern finds herself
stuck, and will likely perish before getting loose.

2.7 ePoxy

The ePoxy Pattern is evident in tightly coupled software modules. As
coupling between modules increases, there appears to be an epoxy bond
between them.

3 Misbehavioral Patterns

Below is a list of eleven misbehavioral patterns.

3.1 Chain of Possibilities

The Chain of Possibilities Pattern is evident in big, poorly
documented modules. Nobody is sure of the full extent of its
functionality, but the possibilities seem endless. Also known as
Non-Deterministic.

3.2 Commando

The Commando Pattern is used to get in and out quick, and get the job
done. This pattern can break any encapsulation to accomplish its
mission. It takes no prisoners.

3.3 Intersperser

The Intersperser Pattern scatters pieces of functionality throughout a
system, making a function impossible to test, modify, or understand.

3.4 Instigator

The Instigator Pattern is seemingly benign, but wreaks havoc on other
parts of the software system.

3.5 Momentum

The Momentum Pattern grows exponentially, increasing size, memory
requirements, complexity, and processing time.

3.6 Medicator

The Medicator Pattern is a real time hog that makes the rest of the
system appear to be medicated with strong sedatives.

3.7 Absolver

The Absolver Pattern is evident in problem ridden code developed by
former employees. So many historical problems have been traced to this
software that current employees can absolve their software of blame by
claiming that the absolver is responsible for any problem
reported. Also known as It's-not-in-my-code.

3.8 Stake

The Stake Pattern is evident in problem ridden software written by
designers who have since chosen the management ladder. Although
fraught with problems, the manager's stake in this software is too
high to allow anyone to rewrite it, as it represents the pinnacle of
the manager's technical achievement.

3.9 Eulogy

The Eulogy Pattern is eventually used on all projects employing the
other 22 Resign Patterns. Also known as Post Mortem.

3.10 Tempest Method

The Tempest Method is used in the last few days before software
delivery. The Tempest Method is characterized by lack of comments, and
introduction of several Detonator Patterns.

3.11 Visitor From Hell

The Visitor From Hell Pattern is coincident with the absence of run
time bounds checking on arrays. Inevitably, at least one control loop
per system will have a Visitor From Hell Pattern that will overwrite
critical data.

4 References

Gamma, E., Helm, R., Johnson, R., Vlissides, J., Design Patterns -
Elements of Reusable Object-Oriented Software. Addison-Wesley, 1995.