Lifelong Learning

Code Readability - Take 3

In my last blog entry on this topic I made the following bogus statement:

"We knew the thing was a Stack, meaning, it implemented the abstraction of a Stack abstract data type, by reading the implementation, and slowly figuring out, "hey, this looks like a stack", and these operations look like operations we normally do on Stacks." to explain how I translated some foreign code into English.

As a reminder, here again is the foreign code:

public interface Pila {
    void agregar (Object o);
    Object extraer();
    Object verTope();
    boolean estaVacia();
    void Vaciar();
}

And here's the Stack "interpretation"

public interface Stack {
    void push (Object o);
    Object pop ();
    Object getTop();
    boolean isEmpty();
    void empty();
}

The statement is bogus, and someone should have taken me to task for making it, (anyone reading these postings?) because you should not have to figure out the semantics of an interface from its implementation. That's pretty circular reasoning. How do you know the implementation is faithful to the "intent" of the interface, if your understanding of the interface comes from your understanding of the implementation?

I could just as easily have translated the Spanish code into:

public interface Pile {
    void add (Object o);
    Object extract();
    Object seeEnd();
    boolean isEmpty();
    void empty();
}

How would I know what's required of the implementation?

What if I had:

public interface Queue {
    void add (Object o);
    Object extract();
    Object seeEnd();
    boolean isEmpty();
    void empty();
}

How do you tell a Stack, from a Queue from a Foo? The answer, lamentably, points out to a glaring deficiency in the Java interface mechanism: the interface cannot possibly tell you the semantics of the defined operations. In other words, a Java interface is inherently unreadable. Claiming that you've read and understood a Java interface would be a vacuous statement. You have no clue what the intended semantics are.

How would you get a clue about the intended semantics?

That's the topic of the next look. Design By Contract.

Code Readability - Take 2

Last week I had some code that was a little bit obfuscated by using a foreign language for identifiers.

Lets see if we can improve the readability of this "foreign" code.

The interface from last week:

public interface Pila {
    void agregar (Object o);
    Object extraer();
    Object verTope();
    boolean estaVacia();
    void Vaciar();
}

If we just use intent-revealing names, we can re-write it as:

public interface Stack {
    void push (Object o);
    Object pop ();
    Object getTop();
    boolean isEmpty();
    void empty();

}

Aah. That looks much better. Now we know the intent of the programmer. But wait, how did we know that Pila meant Stack? We looked it up in a Spanish-English dictionary? We could do that, but what if we did not realize that this was Spanish? When you meet "foreign" code, the "foreign" language is usually a domain you're not familiar with. This is very contrived just to make that point. I hope everyone sees that. Besides, the code could have been as follows:

public interface Shmark {
    void gork(Object o);
    Object fraz ();
    Object sproogel();
    boolean spregel);
    void froogel();
}

We knew the thing was a Stack, meaning, it implemented the abstraction of a Stack abstract data type, by reading the implementation, and slowly figuring out, "hey, this looks like a stack", and these operations look like operations we normally do on Stacks. This required that 1) we had a mental model of an abstraction that we know as "Stack". 2) We recognized the similarity between our mental model and what the code is trying to do. That is the essence of readability. How close can the developer layout his mental model in such a way that it is easy to see it in the code. Much easier said than done!

But is that enough to understand the interface? Not really. We need to specify the contracts that the interface is to honor. The preconditions and postconditions for every method.

We'll do that in the next take.

Code Readability - Take 1

Is this code readable? If it is not, why not? If it is, tell us what it does. Obviously it is a mixture of English and another language. Knowledge of the other language is not required. Or is it? Can you reason through the code without knowing the other language?

public interface Pila {
    void agregar (Object o);
    Object extraer();
    Object verTope();
    boolean estaVacia();
    void Vaciar();
}

public class PilaLista implements Pila {

    private Object elementoTope;
    private PilaLista restoLista;

    public PilaLista() {
        elementoTope = null;
        restoLista = null;
    }

    public void agregar (Object o) {
        PilaLista pilaNueva = new PilaLista();
        pilaNueva.elementoTope = this.elementoTope;
        pilaNueva.restoLista = this.restoLista;
        restoLista = pilaNueva;
        elementoTope = o;
    }

    public Object extraer() {
        if (estaVacia())
            throw new java.util.NoSuchElementException();
        Object tope = elementoTope;
        if (restoLista == null)
            elementoTope = null;
        else {
            elementoTope = restoLista.elementoTope;
            restoLista = restoLista.restoLista;
        }
        return tope;
    }

    public Object verTope() {
        if (estaVacia())
            throw new java.util.NoSuchElementException();
        return elementoTope;
    }

    public boolean estaVacia() {
        return (elementoTope == null);
    }

    public void Vaciar() {
        elementoTope = null;
    }

}

Application Frameworks - Some Thoughts

If you have smart engineers that know their craft, know industry best practices, and know their business domain, why would you need a framework? If you have looked at this issue, or are now looking at it in search of a framework, could you state, in one word, what is the most important consideration that motivates your desire to have a framework?

You can elaborate further, but that probably requires a good deal of space, so lets try to keep it to the one word, for purposes of a canvassing, and maybe a sentence or two in elaboration.

My one word answer: Consistency

My elaboration: I want designs produced by my team, my group, my department, my company to be, above all consistent, so we can have easier sharing of knowledge, easier transfer of knowledge across teams, easier transfer of skills, easier ways of evaluating and judging quality. Different people will have different notions of what "goodness" means - what attributes of a design make it superior to other designs. A framework gives us a common world view, and a common approach to design and construction, a common solution to a set of problems. So I value consistency most.

What is your answer?

An acceptable answer, of course, is "None". We don't need a framework. Would be interesting to read the elaboration accompanying that answer, though.

Other contending one word answers: standardization, productivity, reliability, uniformity, quality, predictability, simplicity. You can add to the list as many as you like, but please choose just one as your overriding concern.

An issue that always arises, or is there as a context on development projects is issue of the relationship between frameworks and projects. I think the relationship should be just like oxygen to a human being. We need it, we breath it, we have it, we don't spend too much time debating how much we need it, how to obtain it, and which is the best technology to provide it.

By the same token, a framework should be available to the project team just as oxygen is. And it is just as vital for their continuing health, as Oxygen is to living things. They should not have to spend any project time debating or selecting frameworks. A framework should be part of their environment, the infrastructure they rest on. The project team should spend every minute of the project time delivering end value to the customer. They need to think through their business requirements, their domain model, the stories they are required to deliver by when, and have total focus on that task.

A framework, therefore, must be provided by a higher order "provider" than the project's immediate builders. It should be part of the environment, or infrastructure. If you are scientifically inclined, the selection of a framework should have been done through a scientific process, based on broader engineering requirements than the needs of one project. If, on the other hand, you are religiously inclined, a framework should be provided by "God" - whoever the Gods of your environment are.

Reading Code - An Example. Spring 2.0.

With a couple of AWK scripts, called from an ANT script, you can - in about an hour - perform the first step of reading a large body of code. The "take inventory step". Here is a pretty quick analysis of the Spring 2.0 source code.

    * 1437 Classes and interfaces.
    * 178 Unique suffixes.
    * Most classes are around 30 lines long. Very few above a 100. Longest class is 269 lines.
    * Class names are long and descriptive.
    * Longest class name is 56 characters: DelegatePerTargetObjectDelegatingIntroductionInterceptor

Reading the Spring class names is very instructive. Extremely expressive names. A great model to follow as a naming standard.

The suffixes that occur more than 5 times with their frequency counts (studying the suffixes give you a good idea of the "concepts" in the code :

150 Exception
79 Bean
67 Utils
63 Resolver
51 Factory
49 Source
48 Interceptor
34 Support
28 View
28 Context
26 Tag
25 Controller
24 Editor
24 Adapter
22 Handler
21 Processor
20 Callback
19 Accessor
17 Manager
17 Listener
16 Parser
16 Extractor
16 Creator
15 Holder
15 Filter
15 Advisor
14 Pointcut
14 Definition
13 Mapping
13 Executor
12 Template
12 Resource
12 Configurer
12 Aware
11 Type
11 Proxy
11 Operations
11 Advice
10 Loader
10 Exporter
10 Assembler
9 Comparator
8 Result
8 Incrementer
8 Attribute
7 Translator
7 Strategy
7 Servlet
7 Reader
7 Operation
7 Matcher
7 Enum
6 Value
6 Request
6 Provider
6 Lookup
6 Event
5 Values
5 Synchronization
5 Status
5 Setter
5 Registry
5 Parameter
5 Locator
5 Helper
5 Attributes

The suffixes alphabetically, with their frequency counts are:

19 Accessor
24 Adapter
1 Adapter102
11 Advice
1 Advised
15 Advisor
1 Advisors
10 Assembler
1 Assert
8 Attribute
5 Attributes
12 Aware
79 Bean
4 Binder
1 Bootstrap
2 Builder
1 Bundle
1 Call
20 Callback
2 Chain
1 Coded
1 Codes
9 Comparator
4 Config
1 Configuration
12 Configurer
1 Constants
4 Container
3 Container102
28 Context
25 Controller
1 Conventions
3 Converter
1 Converter102
16 Creator
2 Data
1 Decoder
4 Decorator
14 Definition
1 Delegate
2 Dialect
1 Discover
3 Discoverer
1 Disposer
24 Editor
3 Entry
7 Enum
2 Error
2 Errors
6 Event
150 Exception
13 Executor
10 Exporter
16 Extractor
51 Factory
1 Factory102
2 File
15 Filter
1 Filters
1 Flow
1 Form
1 Function
4 Generator
2 Handle
22 Handler
5 Helper
15 Holder
4 Impl
1 In
8 Incrementer
2 Info
1 Information
1 Initializer
48 Interceptor
3 Invocation
2 Invoker
1 Lifecycle
1 List
17 Listener
10 Loader
1 Location
5 Locator
1 Log
1 Log904
6 Lookup
17 Manager
1 Manager102
4 Map
4 Mapper
13 Mapping
7 Matcher
1 Matchers
1 Matches
1 Mergeable
4 Message
1 Modified
2 Monitor
4 Multicaster
1 Naming
1 Notification
4 Object
7 Operation
11 Operations
1 Ordered
3 Override
1 Overrides
5 Parameter
1 Parameters
16 Parser
2 Persister
1 Point
14 Pointcut
1 Pointcuts
1 Pool
2 Portlet
1 Preparator
1 Problem
1 Procedure
21 Processor
1 Properties
6 Provider
11 Proxy
3 Publisher
3 Query
7 Reader
1 Record
3 Reference
1 References
1 Refreshable
2 Registrar
5 Registry
1 Replacer
2 Reporter
6 Request
2 Resolvable
63 Resolver
12 Resource
8 Result
1 Results
2 Runnable
4 Scope
2 Sender
7 Servlet
4 Set
5 Setter
49 Source
1 Sql
1 State
1 Stats
5 Status
1 Store
7 Strategy
1 Stream
4 Styler
34 Support
5 Synchronization
1 System
26 Tag
2 Task
12 Template
1 Template102
2 Theme
1 Translation
7 Translator
1 Trigger
11 Type
2 Update
67 Utils
2 Validator
6 Value
5 Values
2 Version
28 View
1 Visitor
1 Watch
1 Work
4 Wrapper
2 Writer

Some typical class names (alphabetical by suffix):

AbstractPropertyAccessor
HibernateAccessor
JdbcAccessor
AfterReturningAdviceAdapter
InstantiationAwareBeanPostProcessorAdapter
TransactionAwareSessionAdapter
AspectJExpressionPointcutAdvisor
AbstractConfigurableMBeanInfoAssembler
DelegatingTransactionAttribute
ApplicationEventPublisherAware
AbstractSingletonProxyFactoryBean
LocalConnectionFactoryBean
BeanDefinitionRegistryBuilder
PersistenceBrokerCallback
NullSafeComparator
ServletContextPropertyPlaceholderConfigurer
SimpleMessageListenerContainer
ConfigurableApplicationContext
AbstractWizardFormController
ServletWrappingController
PreparedStatementCreator
ScopedProxyBeanDefinitionDecorator
PrioritizedParameterNameDiscoverer
InternetAddressEditor
BadSqlGrammarException
BeanNotOfRequiredTypeException
CannotGetJdbcConnectionException
HttpSessionRequiredException
ModelAndViewDefiningException
TypeMismatchException
SimpleAsyncTaskExecutor
RowMapperResultSetExtractor
AbstractPoolingServerSessionFactory
HashMapCachingAdvisorChainFactory
WebContentGenerator
OracleLobHandler
AfterReturningAdviceInterceptor
AdvisedSupportListener
ServletContextResourceLoader
BeanFactoryLocator
HibernateTransactionManager
AbstractHandlerMapping
InterceptorAndDynamicMethodMatcher
MimeMailMessage
HibernateOperations
JdbcOperations
ResultSetSupportingSqlParameter
RemoteStatelessSessionBeanDefinitionParser
DefaultPropertiesPersister
ApplicationContextAwareProcessor
TransactionAwareDataSourceConnectionProvider
TransactionAwarePersistenceManagerFactoryProxy
ModelMBeanNotificationPublisher
SqlQuery
AbstractBeanDefinitionReader
ResourceEditorRegistrar
AbstractCachingViewResolver
AbstractResource
FileSystemResource
RemoteInvocationResult
SchedulingAwareRunnable
DispatcherServlet
ManagedSet
AbstractRefreshableTargetSource
CommonsPoolTargetSource
ObjectNamingStrategy
DefaultValueStyler
JdbcDaoSupport
JtaSessionSynchronization
HiddenInputTag
OptionTag
NamedParameterJdbcTemplate
TransactionTemplate
PersistenceExceptionTranslator
BlobStringType
ClobStringType
BeanFactoryUtils
DataAccessUtils
NumberUtils
AbstractSqlTypeValue
AbstractExcelView
AbstractPdfView
ActionRequestWrapper
OptionWriter

Reading Code - A General Approach

Over the years, when faced with a large body of code, I have approached it as I approach any technical reading task: an exercise in "concept extraction" - a De Bono simplicity technique. The essence of the technique is to try to reduce the sheer size of the problem to a manageable size - a variation of the "how do you eat an elephant" theme. In this post I will deal with reading very large amount of code. Reading a small amount of code (under 10,000 lines), line-by-line, still has different challenges, and is best done in an IDE, like Eclipse, using browsing, searching, and cross referencing facilities, together with some reverse engineering of classes and method executions. But before we get there we have to deal with the problem of size first.

First an anecdotal background to set the stage for the need for a code reading methodology. The largest code reading task I had was about 2 million lines of "legacy" Java code (about 5 years worth of development by about 200 developers) that I had to wrap my mind around when I joined a project at a large financial company. The documentation (although I was given three binders of it) was a couple of years behind the code, and I was told by the chief architect (who hired me) that if I read it, I will get the wrong idea about what the software does. I was part of the software architecture group (one chief architect, one system architect, and 15 subsystem architects). When I was hired, I was promised that I would have 2 hours a day with the system architect for a month, and any time I needed from any architect in the group). I was also promised time with each of 15 team leads and 15 project managers (each subsystem had a subsystem arch, a team lead, and a subsystem project manager as well as a build master). After a month on the job the total time I was able to get from all of these people combined was 3.5 hours. From the system architect, whose boss hired me, I got exactly half an hour - and that remained the average (half an hour per month) for my entire 19 month stint at that project. So the short version of this story is: you can't rely on "knowledge transfer" from others to get to know the system. My job, with an official title of "Subsystem Architect" was really "Performance Analyst". I was to be the software architects' representative with the performance testing and the engineering team (2 distinct teams one does the testing, the other performance modeling and capacity planning). The performance test leads, performance testers, and performance engineers, looked to me for "application knowledge". Since I was hired in from the outside, and have never worked on this project, I needed to ramp up very rapidly, and reading the source code was the only way to do it. Documentation was old. People were not available, and were not allowed to be available. I was not a priority to any of them. The urgency of the task was made clear when I was told that I was part of a 13 person "performance triage team" that had a "check-in" meeting every day at 10:30 am. Each and every day for three months! I was the "look to" guy for "application knowledge". I was greener than a broccoli and colder than an ice cube! You do the math on pressure per square inch.

Faced with 2 million lines of code, documentation you were told to avoid, because it was misleading, and UML that is 2-years behind (they had a full Rose model), how do you learn the system?

The obvious approach, reading the code line by line using a text editor or an IDE, will not be much help. It rapidly becomes overwhelming and lead to frustration and discouragement eventually leading to abandoning the effort. Reading line by line comes at later stage, after the scope of the task has been narrowed.

So here was my general approach, step by painful step:

Step 0. Preliminary: Use the application. Get familiar with what the application does from its user's point of view. Understand the operating concepts. If you can get time with key people, that would be great. In my case I got half an hour with the system architect, and the URL for the app. The architect did a one-page sketch on an 8 1/2 by 11 sheet stating that the system is basically very simple: we have to buy loans and contracts from banks - here is how it flows. The GUI had 110 use cases - but the basic ones are less than a dozen.

Step 1. Inventory the code. What do we have?

- Number of files
- Total lines of code
- Number of classes
- Average size of class (methods per class)
- Number of methods
- Average size of method (lines per method).

I used some tools that were freely available (Understand for Java) was one - for its trial period. I ended up just writing simple scripts to do the counting.

Step 2. Get an overview of the source code tree. What is there other than Java files? Config files, metadata files, XML, HTML,

Step 3. Understand the build process. What are the build-units (build chunks/subsystems/deployment packaging/...)

Step 4. Inventory the databases

- Number of databases
- Number of distinct schemas
- Tables per schema
- Average size of tables (columns per table)

I usually produce a "distilled schema" with this format: <tablename>(colum1, column2, ...) one line per table (only about six or seven columns - pk plus a few more). Essentially a table to me is <tablename>(primary key, info). You can put most databases on one or two pages. It is useful to show foreign keys as part of the info. A very large database (several hundred tables) would reduce to a a few pages.

Step 5. Inventory the main concepts. The database schema is the best source for that. If there is a domain model in UML that would be very nice. Distill the concepts down as much as possible. Most systems narrow down to about a dozen major concepts, while there may be hundreds of tables in the schema, and hundreds of classes in the domain model.

These basic preliminaries give you the big picture. The very big picture. I usually write scripts (mainly in AWK and Korn Shell - even on a PC with MKS toolkit - can't live without it). The scripts filter and summarize the code down to a digestible size.

A most useful script is one that extracts class names and sorts them by suffix. Most systems have class name patterns similar to the following:

XxxxService
XxxxBusinessController
XxxxFlowController
XxxxHandler
XxxxHelper
XxxxBusinessObject
XxxxLocator
XxxxAdapter
XxxxFactory
XxxxAction
XxxxForm
XxxFacade
XxxxBean
XxxxDAO
XxxxDTO
...
XxxxFoo
XxxxBar
XxxxThing
XxxxEntity
XxxxWhatever
....

I like to use AWK embedded in Korn Shell, but you can write a Java program, embedded in an Ant script, or use your favorite scripting language - Perl, Jython, whatever. If scripting gets too hard, I put the code in a database, and analyze it with SQL. On one project I had code for 1000 screens written in an HP 4GL proprietary language that I did not know. The language was pretty declarative and quite elegant. I wrote an AWK parser (simple one) and loaded the code into a relational database whose schema reflected the structure of the 4GL language. Then I wrote a GUI to browse through the code and extract requirements for the new system. The purpose of the project was to port the system fro the proprietary language to Forte - an OO 4GL.

Once you've sorted the class names by suffix, you can determine the number of distinct types of classes the system has. This list of suffixes is a great help in classifying the major concepts (and patterns) used to implement the system. Since there is a tremendous amount of repetition in the implementation (a major implementation pattern is usually repeated hundreds of time), this summarization alone will reveal most of the system secrets. In the financial system, there was a basic pattern of BizController, BizHelpers, BOs, DAOs, and DTOs, repeated 110 times, once for each use case. The architecture standards did not allow deviation from the basic pattern. I could have been saved tens of hours, if one of the architects had clued me in. But, as explained earlier, no one had time to meet with me. Actually, after I arrived at this pattern that most use cases used, and presented it to the architects, they were in denial! No way, our system is vastly more complex than that! Another side lesson you learn, when you start valuing simplicity, is that the "complexity priesthood" will not like what you say! They have a vested interest in complexity. They are the guardians of complexity. If things were suddenly to become simple, they could be out of a job!

The output of this script, a list of the distinct suffixes, and the supporting detail list of the all the classes, becomes "the index" to the system, and a guide to reading it.

Step 6. You can use reverse engineering tools to study the classes. I find the simplest UML the most helpful (just class names, no attributes or methods). For the main use cases, a sequence diagram of the major method can be helpful - if you have a good reverse engineering tool that can reduce the size (which can be overwhelmingly large - some tools will choke on it).

Step 7. Once you have put your arm around the big picture and you understand the "pattern of patterns", so to speak, you can start reading selectively. This is the time to fire up the IDE and start reading. I usually do that one use case at a time - guided by the system's operational concept, or its UI.

Step 8. My main reading goal still remains "concept extraction". What is this trying to do? Why is it doing it this way?

Step 9. One thing that can help is "exploratory testing". Read using the IDE and JUnit tests. Write test cases to explore what the code is doing. This may get complex if the code has external dependencies (accessing external services, writing to databases). You may have to use mock objects to fake any external dependency.

Step 10. Another approach that is useful is "mock refactoring". While reading the code, if it is hard to read, I go ahead and refactor it for readability. The most important refactoring is "extract method", "move method", and "introduce parameter object". Since the body of code is read-only for me, I won't re-check it back in the source code control, I slice it and dice it and refactor it (if it is poorly written).

I think a lot of these steps can be programmed as Eclipse plug-ins. If you know of any, please let me know.

Outrageously Great Software - Starting Thoughts

To be able to deliver great software, we need to be mindful of software quality.

One of the best expositions on software quality I have found is Chapter 1 of Bertrand Meyer's Object-Oriented Software Construction. Nineteen pages of the best advice on what constitutes quality software. Rest of the book (1200+ pages) is very concrete, detailed, and specific design and construction advice on how to actually achieve quality software. The short version of the advice is to focus on correctness. How do you ensure correctness? Design By Contract - Chapter 11.

What are the quality attributes for software? According to Meyer, they are the following:

• Correctness. The ability of software products to perform their exact tasks, as defined by their specifications.
• Robustness. The ability of software systems to react appropriately to abnormal conditions.
• Extendibility. The ease of adapting software products to changes of specification.
• Reusability. The ability of software elements to serve for the construction of many different applications.
• Compatibility. The ease of combining software elements with others.
• Efficiency. The ability of a software system to place as few demands as possible on hardware resources.
• Portability. The ease of transferring software products to various hardware and software environments.
• Ease of Use. The ease with which people of various backgrounds and qualifications can learn to use software products and apply them to solve problems. It also covers the ease of installation, operation, and monitoring.
• Functionality. The extent of possibilities provided by a system. How much functionality is enough? Do you sacrifice reliability, extendibility, etc. for more functionality?
• Timeliness. The ability of a software system to be released when or before its users want it.

Tradeoffs are necessary, as these factors may conflict with one another. Economy often fights with functionality. Efficiency may require perfect adaptation to a particular environment, which is the opposite of portability. Reusability requires solving problems more general than the one initially given. Timeliness may require using rapid techniques whose results may conflict with extendibility. A true software engineering approach implies an effort to state criteria clearly and to make the choices consciously.

Necessary as tradeoffs between quality factors may be, one factor stands out from the rest: correctness. There is never any justification for compromising correctness for the sake of other concerns such as efficiency. If the software does not perform its function, other attributes are useless. I recall a conversation with a client who insisted that we make the software much faster. I explained to the customer, that I can make it extremely fast, if it did not have to do all these things that he wanted it to do. That is the definition of a useless quality attribute! Very fast, but doesn't do much.

So I maintain that outrageously great software is software that does what it is supposed to do, in other words, honors its contract with its potential users. A user of a piece of software, most of the time, is another piece of software. Only the UI modules of a software system have humans as the end user.

So to deliver great software, it would pay to know how to make a software module honor its contracts with other software modules (tests are those software modules that represent the user). This leads to the realization that great software boils down to DBC - Design by Contract!

Other definitions, of course, abound. Great software is great because:

- It generates great revenue for the company.
- It is a great market success
- It is great performing. Lightning fast.
- It has a great user interface.
- It is bug free. Never breaks down.

You can deliver great software by other means, like test-driven development, and by being relentlessly test-driven. Having explicit contracts checkable at runtime, is complementary, and will get you there faster.

A System Development Process Using ORM

Outline of an agile, and very rapid, system development process utilizing ORM (Object Relational Mapping). Hibernate is used as an example to make the discussion more concrete, but any ORM will do.

1. If you have an existing data model extract your domain object model from it. Refactor object model to fit your requirements.

If you don't have a data model, come up with a domain object model from your requirements. Create a database schema from the domain object model. Don't go to step 2 until you have a domain model synchronized with the data model (synchronized does not mean identical!). If you are allowed to refactor the data model, do it. If not, live with it (and curse the DBAs!), but refactor the object model you must. If you have a highly denormalized data model, normalize it using Hibernate components and class-hierarchy mappings. Decent thought work needs to go into this. Can't be blindly automated.

Don't follow mad processes, like RUP, that tangle you up in use-case hell, and an object model that "falls out" of the use-case model through a bunch of VOPCs (View of Participating Classes). That's total hooey. Nail down the domain object model. Look into domain-driven design (Eric Evans).

2. Do steps 2.a and 2.b in parallel.

• 2.a Create a skeletal (canonical) implementation of the data access layer's API using HQL and DAO objects (I prefer DataManager Objects).
• 2.b Define and implement unit and acceptance tests for the data access layer's API. This should be much simpler than the tests for the domain layer, since you are mostly implementing CRUD operations. But make sure at this stage to test business rules and data integrity rules (mainly having to do with correct object creation/deletion and relationship maintenance). You don't need to worry about business logic or business process at this stage. This separation of concerns can save you great deal of work later and is key to robustness of the domain layer which will rest on top of the data access layer.

3. Do steps 3.a and 3b in parallel

• 3.a Implement the domain layer. You can proceed one-story at a time, or one subject-area (a set of collaborating objects) at a time. I prefer the latter, but your project tasking may differ (if planning by story).
• 3.b Define and implement unit and acceptance tests for domain layer. Now is the time to think about business process and business logic. Use an acceptance testing framework like Fit (Framework for Integrated Tests - Ward Cunningham). You are resting on a solid foundation of a tested data access layer.

Note that in both layers you can follow test-first, or test-last approaches. I prefer test-first. It makes tests drive the development - but that is not a requirement - merely a preference and a sequencing decision. First, or last, make sure you have sufficient unit and acceptance tests implemented.

4. Implement continuous integration making sure your unit test suite and acceptance test suites run with each integration.

5. Don't let the GUI distract you. Implement as little of the GUI as you can get away with - preferrably none. Once the domain model API is functional, stable, and robust you can pay more attention to the UI. If the UI is necessary for demonstration to stakeholders, implement the UI in slices on top of fully tested domain layer. I like to implement a complete text ui, or a domain-specific language,  that exercises the domain APIs.The GUI is left to the usability and presentation layer specialists, who will use the text UI to learn and exercise the API before they hook into it. They can have all the creative freedom they need to come up with the most user friendly and the best user experience they can come up with, comfortably knowing what the domain layer is capable of giving them.

Note: Many customers will not allow the implementation of a text UI, or a domain-specific language (as it seems unnecessary, since the text ui, or the language interpter, is not made available to the end user), but for those customers who allowed me to use it, specacular results in terms of a very rapid schedule, and very performant code, were achieved. In the schedule, I put that layer under "acceptance test framework", and that was acceptable to customer management, who were glad to pay for the high quality and the rapid schedule.

Constructive Confrontation

At Intel, the largest semiconductor maker in the world, all full-time employees are given training in "constructive confrontation", a hallmark of the company culture. Intel preaches that the only thing worse than too much confrontation is no confrontation at all. So the company teaches employees how to approach people and problems positively, to use evidence and logic, and to attack problems and not people.

Intel's approach is backed by a series of experiments and field studies done at the Kellog Business School, Wharton Business School, and Stanford showing that destructive conflict is typically "emotional", "interpersonal". Groups that fight in these ways are less effective at both creative and routine tasks, and their people are constantly upset and demoralized. In contrast, these researches find that conflict is constructive when people argue over ideas rather than personality or relationship issues, which they call "task", or "intellectual" conflict.

The above two paragraphs are both verbatim from a recent book by Bob Sutton, The No Asshole Rule.

Also checkout this site.