Malcolm Davis's Blog

September 2004 Archives

It depends

In Anti-Pattern - The Swiss Army Effect, John Reynolds expresses concern of the expansion and growth of Java technology, and the technology overlap that is occurring. For instances where does one go for database CRUD operations? JDBC, JDO, CMP? Web development can be just as frustrating. Web development products include JSF, Velocity, Struts, Tapestry, and Jetspeed for starters. The large selection provides grief to many.

The hammer
"If the only tool you have is a hammer, you tend to see every problem as a nail." - Abraham Maslow

Microsoft's claim to fame is their one homogenous, well-integrated, do it all environment. Even though Microsoft VisualStudio falls way short of free tools like Eclipse, and the .NET architecture is lacking features like an Object/Relational Mapper (ORM), the developers don't have all those decisions to make, they just make what they have work. Is it choices that breed discontentment?

The hammer mindset is understandable. Getting a solid grasp around just one of the tools is difficult. Both developers and customers try to learn one technology and apply it to all problems. Trying to look at the market place and second-guess the future is equally dreadful.

It depends
The experienced engineer seems indecisive. Whenever asked a question, the engineer simply replays with 'it depends'. What is the web site developer trying to accomplish? If it's a static content site, maybe Cocoon is the answer. Is it's a portal site, maybe Jetspeed. Perhaps Struts if the site requires dynamic web forms. Does the customer allow open source? Has the customer already invested in a specific technology? Who are the other developers on the team? What is the time frame of the project?

Knowing the basics of solid development far outweighs which package/technology/tool used. Tools & technology change, concepts and practices just adapt to the changes.

Final thought: Regardless of the profession, doctor, lawyer, or engineer, the focus is on the 'principles' and not the 'tools'. Being a great doctor does not change based on new drugs or procedures. Great doctors work to understand the unique needs of the patient by doing such things as analyzing symptoms, understanding the patient history, and simply listening.

Conflicting mindsets of C# vs. Java

I was recently asked to compare C#/dotNET to Java/J2EE. I began by thinking in terms of features, products, technologies, and then I realized that C# and Java isn't a battle over features, it is over mindsets.

When sitting at the company's workstation, the developer is faced with 2 opposing mindsets:
1. Accepting the tools that are provided on the desktop as the norm.
2. Constantly exploring opportunities for increasing productivity.

Acceptances vs. exploration are major conflicting mindsets. Knowing what is best for the developer, acceptance relinquishes control over the tools and behavior to the manager and friendly vendor. The exploration mindset is the developer looking for, and finding the right tool for the job. Both have their pros and cons.

Tool exploration (in the form of IDE, components, or tools) is natural, expected, and a preferred behavior. As developers, we should explore new ways of increasing productivity by new processes, automating repetitive tasks and component reuse. However, this continuous exploration and improvement is a threat in the corporate world. In many corporate shops, IT policy is to limit installs to the desktop. Many restrict external web site access, and some go as far as restricting access to newsgroups and blogs. [Yes, It is difficult to comprehend that some IT shops even block the blogs at java.net.] These IT shops have many valid concerns. Virus and spyware plague infrastructures. Licensing issues strike fear into legal departments, and many programmers are unaware of the consequences of introducing new software into the environment.

Four years ago, I introduced Ant, Tomcat and JUnit to a major IT shop. The tools significantly improved productivity by making web programming, testing and building simpler and faster. It would seem that every developer and manager would instantly embrace these technologies. For the reasons described earlier, big brother IT brought a stop to everything. [Eventually, many years later, the tools were finally approved in the big IT shop.]

NAnt and NUnit are just a few of the .NET open source counterparts to the Java toolset. However, instead of embracing, enhancing, and integrating the tools into their product line, Microsoft has created their own counterpart called Visual Studio Team System. Change gears for a moment, and imagine if you can, any Java IDE saying, "we are not going to support JUnit or Ant, we are going to construct our own tool set". Hard to imagine? You now understand the different mindset between Java and dotNET. One embraces the realities of developers constant strive for productivity, while the other strives to provide their vision of a single integrated solution. Since corporate IT groups desire a single integrated solution, the Microsoft Team System makes perfect sense. However, the Team System is only about 5 years behind the times, which is about where Microsoft technology base sits.

Those in the commercial world may have started using Ant and Tomcat from the original release on Jakarta. The mindset highlights one of the major differences between commercial and IT development. If commercial software followed the same rules as corporate IT, it would impact their competitive edge, as well as lose their best developers.

As IT shops move forward to adopting external sources for software, generally in the form of Application Service Provider (ASP), Java and open source will become mainstreamed into IT. Microsoft's style over substance approach to software development will eventually bite them. The ASP business model has started us into the era of commercial software development. Industrial strength development techniques, cutting edge technology, and the constant exploration for opportunities to increase productivity, will become the norm, and we will see "the little fish eat the big fish", and see Java eat dotNet's lunch.

Planning: Managers need to sell their trucks.

Not too long ago, I worked for a large IT shop that required their employees to wear an electronic leash called a BlackBerry. At all hours of the day, day or night, the customer, the manager or other developers could contact me. This form of instant communication lead to constant fire drills and little "flow time".

"Flow State is a relaxed state of total immersion in a problem that facilitates understanding of it and the generation of a solution for it." - Steve McConnell. In "Peopleware", DeMarco and Lister determine that there are several factors in developing world-class software. One of these factors is the ability to be in an environment that supports the "flow state" and allows developers to minimize interruptions when desired. Another is scheduling which allows members to "have a life" outside of work. DeMarco and Lister wryly note, "they will anyhow."

Many years ago I considered building a house. To help with the process, I took a contract seminar from a leading homebuilder in the Atlanta area. The seminar focused on patterns and anti-patterns, (or as he referred to it, "the mosquitoes that bite you").

"Sell your truck" was the number one recommendation of the 2-day seminar. [An odd thing from a southern good ole boy.] He mentioned that the key to his success was planning, and he did not really start planning until he sold his truck.

For many builders, the truck is a convenience item that allows for quick trips to the lumberyard, plumbing suppliers or flooring outlet. A truck was the only requirement for getting items to the job site. However, time in the truck was time not supervising, working on other homes, or meeting with new customers.

Even though selling his truck was extreme, it forced him to plan. He found that vendors would deliver products to the job site. He developed checklists and scheduling timelines, and found ways of handling one of the biggest problems on a project, the plumber. Good plumbers are difficult to find, are never on time, under-estimate jobs, can be temperamental, and generally charge too much for their work. [Managers can make their own plumber analogies.]

Planning is a difficult task, and it is human nature for people to rely on every crutch possible. However, some times the crutch needs to be removed for people to learn to walk. One of my top recommendations for this mammoth IT, with thousands of developers, is to eliminate BlackBerry's from the development staff. Eliminating the BlackBerry’s would not only help the development staff by providing flow state, but also force the mangers to become better planners.

This work is licensed under a Creative Commons License.