Fifty or more Eclipse projects for a single medium sized web application is too many! My default rule for an application with a few hundred classes:

• Use the package system. You can keep your source code in two directories src and test.

Googling around for guidelines for projects and workspaces hasn’t revealed much. And little advice on how to refactor a nasty tangle of projects. The current plan:

1. Take the java only projects and combine the source code directories one at a time.
2. Run the tests. OK, legacy system of course very few tests to run. Will have to make do with high level smoke tests in the GUI and some manual checking.
3. Next, take the same approach with the web projects.
4. Finally, celebrate a little with a simplified project structure.

My perspective is limited to my experience. Perhaps there are great advantages to having many small projects for a small to medium sized web application. Feel free to comment with any better ideas.

Carl Quinn, a development manager at Google and a member of the Java Posse, mentioned that he spent about 50% of his time on code reviews. Google even has a special code review tool, Mondrian, developed by Guido van Rossum. The features are similar to Crucible.

Google’s warm embrace of lightweight code reviews sets a nice bar. We’ve heard for decades that code reviews or inspections are great for removing defects, keeping the code base maintainable, and mentoring. But…

• There’s no time, we have code to write.
• I have a healthy ego, I’m not comfortable with my peers giving me feedback.
• My code already works, it even passes those unit tests I wrote at the end.
• Code reviews are just about individual style, not worth the time.
• We’ll pair program then we don’t have to do code reviews. Oh, you mean I have to sit with another developer and share a machine? Let me think about those code reviews again.
• Code reviews, those aren’t Agile.

Can Google’s example win over more developers?

David Siegel of Creating Killer Web Sites would be proud. Rands has composed an entrance tunnel leading to the home page for his new book Managing Humans. Rands terms it a ‘SLIDESHOW’ but there’s no hiding an entrance tunnel. I shed a tear remembering the last time I visited a site through an entrance tunnel back in the late 90s.

I’ve already ordered the book.

Brows furrow, fists clench, throats tighten. Our domain logic is lost in legacy systems. I look back at any significant project that interfaces with our mainframe and see lost opportunities. We could have real domain objects interacting with relevant behaviors, but instead we dutifully write dozens of data objects full of getter/setters and little else. We pass off all the business logic and processing to the mainframe.

Even time is a concept we’re asked to check with on the mainframe. Since there’s some strange issues in some of the legacy code and the entire design paradigm was to run everything in a batch mode we can’t even rely on time. Real world time is useless. Setting your time by Network Time Protocol (NTP) is dangerous. Time is just a setting to control when your jobs run.

Mike Witters has seen the anemic domain model as well:

There was almost no logic involved outside of validating UI input. Almost everything from a logic perspective was encapsulated into the legacy systems or database queries: pricing, searches, margin calculations, etc.

We’re still working on it, but if most of your domains are left to your legacy systems you really don’t see the benefits of OO. The promise of a healthy domain driven design remains. Future web mainframe integration projects discussions will center around these ideas.

try {
  AddressEntityBean addressEntityBean = addressHome.findByCityAndStreet(city, street);
  addressEntityBean.remove()
} 
catch (Exception e) {
  //this guy is already gone
}