February 2005

Monthly Archives

Java Software Factories: Part 11 – Requirements Flexibility

Java Software Factories: Part 11 – Requirements Flexibility

Project sponsors rarely know exactly what they really want. It’s not their fault, really. A project sponsor would have to be truely remarkable to anticipate and document every requirement in advance. It’s reasonable to expect that new ideas will emerge (good developers often get into the spirit of the project and suggest improvements) or gaps will be spotted as soon as a solution is tried by end users for the first time. From personal experience, if the project is for a software product, then the product manager will by under constant pressure from the sales team to add new customer requested features.Business requirements can change mid project even if the project sponsor has done a good job decribing the initial requirements.

Rather than complain about moving targets, developers should anticipate that the project is not finished even if all the requirements are satisfied.

Simple message: assume the deliverable is a moving target.

One essential element of Java Software Factories is the ability to deliver results quickly (for example, cutting out protracted architectural discussions and vendor selection at the start of a project). But the true key to speed is code generation of as much as sensible of the application. Code generation also means code re-generation. This means that changing requirements can be accomodated really quickly.

PJ Murray
CodeFutures Software


Java Software Factories: Part 10 – Managing Software Developers

Java Software Factories: Part 10 – Managing Software Developers

For various reasons, many organizations seem to have problems managing the activities of software developers.In defense of software developers, it should be noted that many of the problems are due to poor management.

Perhaps one of the biggest problems is that many managers are non-technical or have out-of-date technical knowledge. That makes it difficult to monitor software developers.

Another problem is that some highly techical managers don’t have the soft skills (people management, etc).

But mainly, the problem lies with the software developers – lack of commercial understanding, lack of discipline regarding deadlines, more interest in trying new technologies, etc

Java Software Factories provide a framework for controlling the activities of developers – focussing their creative efforts on solving business problems.

PJ Murray
CodeFutures Software


Java Software Factories: Part 9 – Factory Components

Java Software Factories: Part 9 – Factory Components

It’s really amazing how often software developers “reinvent the wheel”. Even CodeFutures is guilty of it sometimes – we’ve just ripped out our inhouse XML parser and replaced it with a standardized component – JDOM.It requires a determined effort to identify and then stick to a common set of components. And it will require an even more determined effort to use them in a cohesive way – which is where Java Software Factories are useful by providing a context and methodology.

The building blocks for most Java Sofware Factories already exist.

There are many great specifications, standards, and products that have gained widespread acceptance already:

Core J2EE Design Patterns
Security – Liberty Alliance, SAML
Diagnosticsa and logging – log4j, JMX, and SNMP
Property Management – JNDI
Persistence – DAOs, JDBC, JDO, EJB CMP
Presentation – JSPs, Struts (perhaps JSF later?)
Integration – MOM and SOAP

Application Servers – J2EE, Tomcat, etc
Build tool – Apache Ant
Code documentation – JavaDocs
XML parser – Xerces, JDOM

XSLT – Xalan

At a another level, there’s a wide range of technologies that can and must be leveraged for the Java Software Factories – operating systems, relational databases, and much more.

An organization can standardize on which components it uses within its organization when constructing factories.

Standardization on specific components may sound obvious – but how many organizations do it?

PJ Murray
CodeFutures Software


Java Software Factories: Part 8 – Project Scheduling

Java Software Factories: Part 8 – Project Scheduling

Sometimes projects have immovable deadlines. Products have to ship in time for a key trade show, changes are made in tax laws, or technical standards change.Sometimes the amount of work in a project is deliverately underestimated by management (or more likely sales) in order to submit a winning big for work.Feature creep does not help either. A project that begins with a realistic schedule can quickly get out of control.

However, the most common reason why software development projects are delivered late is that they are poorly estimated.

Java Software Factories can help provide accurate project schedules.

The most obvious way is that each time a software factory is used, the time required for each part of the project can be measured. Do this several times for the same software factory and you will have very good time estimates.

For new software factories, previous experience with other factories will provide accurate estimates for at least some components of the software factory.

PJ Murray
CodeFutures Software


Java Software Factories: Part 7 – Craft versus Engineering

Java Software Factories: Part 7 – Craft versus Engineering

I’m an engineer. Well, to be more accurate, I have a degree in engineering from Trinity College, Dublin. While the work I do is pretty technical, I’m not really writing any code (HTML does not count).The reason why I’m mentioning my engineering degree is that it’s a broad rather than deep course. All of the first and second years are common to all students – no electives. So I was exposed to a wide range of engineering subjects – mechanical, environmental, civil, computing, as well as a lot of math (so much math that I also have a degree in math as well).

There was nothing in this broad technical education that led me to believe that I was an technical artist or a craftsman. Yet many software engineers believe they are craftsmen.

So where does this come from?

At college, I remember the structural engineers used to joke about the architects drawing pretty pictures while they actually designed the real structure. I remember a discussion between mechanical engineers wondering why Waterford Crystal hand cut its crystal when lasers could do a faster, better job.

The computer engineers were no different. About three quarters of their course was the same as the rest of the engineers.

So why do so many computer engineers and computer scientist suddenly forget everything they have learned about taking a rational, scientific approach to problem solving when the start their professional life?

Setting up a Java Software Factory by a computer engineer should be no different than a mechnical engineer setting up a car factory.

The good news is that Java Software Factories offers a way to channel the creative energies of software engineers.

PJ Murray
CodeFutures Software


Java Software Factories: Part 6 – Development Scalability

Java Software Factories: Part 6 – Development Scalability

Great software engineers can improvise solutions for just about anything. Innovation comes naturally to them. They are often very fast at coding too.Good developers are often asked to mentor weaker or less experienced developers. They guide their apprentice much the same way that craftmasters guide their apprentices.

The problem is that apprenticeship does not scale. There’s a limit to the number of great developers that are also good at mentoring and how many junior developers they can train at the same time.

An alternative is to only hire experienced, innovative developers.

Even if you could hire dozens or hundreds of innovative software developers that can patch together solutions to each problem that is thown at them, the result will be chaos.

The problems will start once application integration starts.

The consistency of the Java Software Factories approach provides development scalability. You can have a dozen teams in a dozen locations, mainly consisting of less experienced mainstream developers guided by Software Factory architects, all developing consistent applications with the same approach and same architecture.

We will still need some clever, innovative software engineers. They can be thrown at the difficult problems. They can be the Java Software Factory architects.

PJ Murray
CodeFutures Software


Java Software Factories: Part 5 – Mainstream Developers

Java Software Factories: Part 5 – Mainstream Developers

Hiring a sofware developer is a high-risk decision. There are several things about the way software applications are typically developed that makes a difficult hiring decision almost like a game of Russian Roulette.Hiring for a specialist skill is a typical weakness in the hiring process. The problem with this approach is that most skills are technologically obsolete in a few years. Hiring for ability to learn is more useful in the longer term, but much more difficult to do and requires a lot of disciple. Take a look at any typical programming job advertisement, and you’ll see that that hiring for flexibily/adaptability is not how the job market typically works. It’s all about solving a short term need. It’s about “WebSphere developer with 4 years banking applications experience” rather than “Flexible developer with positive outlook and wide experience”.

Java Software Factories reduces the risks involved in hiring software developers. If all the major architectural decisions, technology choices, and tools are predetermined, the chances of one individual engineer going off in a strange and wonderful, intellectually pleasing or technologically interesting direction are nill. So you can hire the creative developers since their energies will be channeled in the right direction (solving business problems, which usually means writing the business logic and focussing on the end users).

What’s more interesting is the profile of most of the developers that can be hired. Because many of the harder technical decisions have been made before the start of the project by Java Software Factory architect, and tools are available to assist and control the developer output (the Java Software Architect configures the factory), it means that less skilled, more mainstream developers can be used. Senior developers will always be required to design the Java Software Factory, supervise and lead the mainstream developers, and maybe write the business logic.

There are not enough senior and experienced Java developers. That means Java needs the mainstream developers – it needs to be to attract developers from huge pool of Visual Basic developers. Java Software Factories is the way to manage it without them getting hopelessly lost from having to choose between dozens of application servers, many data presistence strategies, several presentation tier technologies, etc.

PJ Murray
CodeFutures Software


Java Software Factories: Part 4 – Reuse

Java Software Factories: Part 4 – Reuse

Code reuse was supposed to be one of the major benefits of object orientation. Of course, I’m old enough remember that it was also supposed to be a key benefit of structured programming. I’m not a DBA, but I can guess that reuse is also touted as a key benefit of using Stored Procedures.But I have never really seen systematic code. It seems to be quite rare, in fact, because I did a quick check with some developers to confirm my impression is correct..In fact, the opposite of reuse, reinvention, is actually more common. It’s far more common for software developers to want to throw away code, the existing architecture, choice of tools and platforms, and start from scratch. This happens all the time. It even happens when it’s strategically very the wrong decision to make (think about what happened to Netscape’s market share while they wasted years rewriting Navigator). And it happens on all the time when its technically unnecessary and tactically not the best use of development resources.

It does not help that many software developers want to try out unproven new technologies – which is far more interesting than getting on with the daily grind of writing code.

One of the main reasons for all this waste is that other people’s code is difficult to read. Even with internal coding style guides, developers produce very different solutions to the same problem.

Some of the fundamental principles of Java Software Factories will help eliminate reuse problems:

Design patterns: it’s much easier to recognize a design pattern and therefore read the code. Start with the Core J2EE Design Patterns.

Code generation: it’s much easier to make a simple change and then reapply the code generator

Systematic architectures: if particular types of applications within an organization always have the same architecture, it’s easier to understand the source code.

PJ Murray
CodeFutures Software


Java Software Factories: Part 3 – Core J2EE Design Patterns

Java Software Factories: Part 3 – Core J2EE Design Patterns

A group of senior Java engineers at Sun Microsystems has worked very hard to produce the Core J2EE Design Patterns. These patterns represent the best practices in J2EE design are one of the most important elements in industrialization of Java application development. The core design patterns allow developers to leverage the knowledge and expertise of Java gurus.If your developers are refusing to use the core J2EE design patterns, try asking a few questions:

Are they able to produce a better design pattern than the recognized experts?
Will the non-standard design patterns be easy to read by third-party software developers?
Will it be possible to hire engineers with experience of their custom design patterns to reduce long term maintenance costs?
Will they document the design patterns as well as Sun has documented the Core J2EE Design Patterns?
What form of peer review process to they propose to prove their alternative design patterns are better than the core J2EE patterns?

The benefits of using the Core J2EE Design Patterns are only described very briefly, and perhaps understated, in the first chapter of the book Core J2EE Patterns: Best Practices and Design Strategies.

If professional application developers in a commercial environment want to re-write or redesign the core J2EE design patterns, I suggest that they are a) not focussing on real business problems b) have too much time available c) don’t understand the realities of commercial software development and perhaps should consider an academic career. If they really have the time to design alternatives to the core J2EE patterns, it’s time to downsize.

PJ Murray
CodeFutures Software


Java Software Factories: Part 2 – Predictable Results

Java Software Factories: Part 2 – Predictable Results

My first software development projects were solo efforts. I wrote what were then called “adventure games” for the Sinclair ZX Sprectrum. I was the project sponsor, project manager, chief architect, development team, testor, and also the target profile for the end use of the product. It was actually all fairly straigtforward. Software was shipped on cassette tapes and pre-Internet distribution channel was the local computer shops in my home town, Dublin. It was not about making money anyway. I just liked, and still like, the whole concept of software products.

My first professional software development projects were with Ericsson. We produced telecommunications software that ran on telephone switches called Service Control Points. The management software for administration of the software on the switches was client-server based with Solaris servers and Windows clients. The architecture was always the same regardless of the actually application (see Java Software Factories defintion). The development process was highly controlled and the quality of the software was, in retrospect, flawless. There were similar software development centers in several other parts of the world and I’m fairly confident that they all produced equally high quality products. However, there was a price. The projects were very slow, process driven, and documentation heavy. The financial cost was huge and even a minor change request could take months.

I left Ericsson to join Logica’s Mobile Products Division. I only lasted 6 months. The person I was working for, Joe Cunningham, was an amazing visionary. As the product manager for 3 products, I had 3 program managers and 3 technical architects. All of them were excellent. The team of product managers that I worked with was first class. The marketing department run by Norbert Sangard was also excellent. And I resigned after 6 months, the week my probation period was due to end. The reason was the software development process was broken, conflict ridden, highly political, and unable to deliver on the business requirements.

Why is it so difficult to develop software applications? I have only ever worked with one group of developers that could consistently deliver projects on time, on budget, and with the required quality. It was a team lead by Lars Stavholm, Brendan Phelan, and Ove Rosenlund and the minimum requirement to join the team was 10 years experience. They were the exception that almost proves the rule, because very few development teams have the luxury of having a “superstars only” rule.

I have been thinking about this issue for several years, and describing a solution to CodeFutures customers for the past 18 months.

The aim of Java Software Factories is to deliver predictable results.

I’m borrowing the term “predictable results” from Lars Stavholm.

Not every team can be composed of Lars Stavholm and his band of superstars, so that’s where Java Software Factories are neeeded.

Java Software Factories are about reliable and predictable application development through automation, design patterns, consistent technological and architecture choices, sensible development processes, and of course, appropriate software development tools.

PJ Murray
CodeFutures Software


Page 1 of 212