Category Archives: Design

Project Communication

Many software projects fail to deliver on-time and on-budget and a factor in that is normally inefficient project communication. Studies have shown that software teams that consistently deliver on-time and on-budget communicate in an effective manner. These teams stay in contact constantly, but wisely use each other’s time during the communication process and are careful not to waste other people’s time. Below are some tips for enhancing project communication when working in software development projects:

  1. Set up an online repository for documentation – For effective communication, all your project documents should be online, up-to-date, and available at everyone’s finger tips. This includes requirement documents, detailed designs, test plans, project plans, status reports, user acceptance plans, post mortem documents, etc. Having all of these documents at everyone’s disposal ensures that everyone is working on the same set of deliverables. Many groups usefully solve this problem by setting up a department Wiki that acts as a convenient location for storing and updating important project information such as documentation.
  2. Specify Clear Roles and Responsibilities – For effective communication, everyone on the team should know what their role is and what they are accountable for. Each role should be documented during the initial phases of the project and every team member should sign off on their responsibilities. Post these in your online documentation repository.
  3. Monitor Employee Performance – Each employee should have defined goals and should be measured against their goals monthly or quarterly (depending on project duration). Goals should be specific, measurable and achievable. Progress to goals should be based on objective measurement.
  4. Progress Reports – Progress reports should be created weekly. This can be as informal as creating a weekly status report for management review or as formal as creating reports using a project planning tool. Consider using a tool for this, some good ones are Software Planner and Microsoft Project.
  5. Make Decisions based on Facts – All decisions should be objective and should not be self-serving. Decisions should be based on facts, performance and in the spirit of improving overall team performance.
  6. Project Tracking should be done Online – All phases of the Software Lifecycle should be managed online, preferably via the web. This includes managing of requirements, tasks, issues, defects, test cases. sharing knowledge with discussion forums and your document repository.
  7. Be Careful of People’s Time – It is good to have periodic meetings, but the presence of solid project tracking tools eliminates many of the long-winded meetings that teams have. Team members are most productive when they know their roles, responsibilities and have a way of showing progress online. This can greatly reduce the number of face-to-face meetings that are needed. (Thanks to Steve Miller of Pragmatic Software for insights into these issues.) Gregg Kellogg

Web Design Goals

Working with legacy software systems provides its own considerations, but there are some general goals that can be stated for web-based software applications. To the degree that the nature of system upgrades substantially touches these areas of system design, it is important to consider the following goals within the system design. Well designed applications should meet the following goals in order to provide lasting value:

  • Be robust – Enterprise software is important to an organization. Users expect it to be reliable and bug-free. Therefore, it is incumbent on the design team to use the best possible software practices build robust solutions and ensure that the code is of the highest quality.
  • Be performant and scalable – Enterprise systems must meet the performance expectations of their users. They must also exhibit sufficient scalability – the potential for an application to support increased load, given appropriate hardware.
  • Take advantage of OO design principles – Object Oriented (OO) design principles offer proven benefits for complex systems. Good OO design practice is promoted by the use of proven design patterns – recurring solutions to common problems. The concept of design patterns was popularized in OO software development in Design Patterns: Elements of Reusable Object-Oriented Software.
  • Avoid unnecessary complexity – Practitioners of Extreme Programming (XP) advocate doing the simplest thing that could possibly work. The lesson is to be wary of excessive complexity. Complexity adds to costs throughout the software lifecycle. On the other hand, thorough analysis must ensure that we don’t have a naive and simplistic view of requirements.
  • Be maintainable and extensible – Maintenance is by far the most expensive phase of the software lifecycle. It’s particularly important to consider maintainability when designing Enterprise systems. A well designed application will be useful to an organization for years and must be able to accommodate new business needs. Maintainability and extensibility depend largely on clean design. We need to ensure that each component of the application has a clear responsibility, and that maintenance is not hindered by tightly-coupled components.
  • Be delivered on time – The objectives of clean design must not eclipse the need for an efficient and productive development cycle. The use of development environments and frameworks that ease the development process and help implement proven design patterns is an important part in considering a development project.
  • Be easy to test – Testing is an essential activity throughout the software lifecycle. We should consider the implications of design decisions for ease of testing.
  • Promote reuse – Enterprise software must fit into an organization’s long term strategy. Thus it’s important to foster reuse, so that code duplication is minimized. Code reuse usually results from good OO design practice, while we should also consistently use valuable infrastructure provided by the application server where it simplifies application code.

(Portions of this entry are derived from J2EE Design and Development by Rod Johnson.)

Thoughts on Extreme Programming

A popular trend in systems development circles is the so-called Extreme Programming Paradigm. XP has proven to be quite effective at rapidly producing system functionality, and it includes many practices that should be considered by any development team (e.g., Test Driven Development or TDD). However, there are many pitfalls to XP that don’t necessarily make it the best technique for many organizations. Extreme Programming is a technique that is used to much profit by many organizations today. In contrast to the more “rigid” documentation guidelines outlined above, Extreme Programming is characterized by a much more streamlined time-bounded development process. Typically developers work in teams and communicate directly with the stakeholders. They then choose a part of the problem to focus on and develop something in a fixed amount of time; to the degree that features cannot be accommodated within the stated time frame (often weekly, sometimes monthly), these features are ignored in order to have something to show. The stakeholders then inspect the result and suggest modifications or improvements to the developers who continue with the process until the stakeholders are satisfied. While this can be very effective at showing progress in the short-term, it suffers from a lack of long-term memory. Over time, stakeholders change or original goals were forgotten. Extreme Programming is best suited for ephemeral projects, such as a consumer-facing website, that often don’t have a lifetime beyond several months. It is inappropriate for corporate development of mission critical systems that have complicated requirements and whose stakeholders can change over time. Successful corporate development efforts borrow the best practices from Extreme Programming, such as Test Driven Design and Pair Programming along with the most useful of the Waterfall design practices, such as the reliance on use cases and functional specifications, to create lasting products.

Managing large projects

Of paramount concern in managing large development efforts is the need to ensure that the application remains relevant and maintainable and can be kept up-to-date with the requirements of the rest of the organization. The danger of a long running project managed by a limited pool of developers is that the original requirements and goals of the system can be lost in the face of multiple enhancements. This can lead to a system that is arcane, does not reflect the actual needs of the department, and (most importantly) is over-reliant on the internal knowledge of the development team. This poses a substantial risk to the business that relies on the system for day-to-day operation. Fortunately there is a long standing body of Industry Best Practices that have been used to successfully manage the lifecycle of large-scoped projects. h3. Industry Best Practices The principal means of managing large software projects is to ensure that the problem domain and the software system are well understood. In a corporate sense, this means that the workflow, project history, system concept, design and implementation are fully documented and kept up-to-date throughout the product lifecycle. Such practice requires diligent management, as it is in the nature of people and organizations to lapse into ad-hoc knowledge and provincialism.

Communicate with Stakeholders

Identifying who the stakeholders of the system are and involving them intimately in the design process is key to ensuring the successful outcome of any development project. A software system can be coded to the highest standards, completely tested and run quickly and without bugs, but if it doesn’t actually solve a problem the end users need, it may as well never have been started. Stakeholders include end users, management, system architects, developers and system administrators. They also should include stakeholders in other systems that must interface with the system being designed.

Understand the Problem Domain

Create a concise statement of the business practices the system is addressing. This Concept Document should lay out the high-level requirements of the system in a way that the stakeholders can use to understand their relationship to it.

Involve Stakeholders

Create Use Cases to describe the interaction of stakeholders with the system. In conjunction with the Concept Document, this will result in a detailed Requirements Document. This process should be interactive with the different stakeholders so that the fully understand the purpose of the system and how they will relate to it. This is a principle opportunity to ensure that everyone is “on the same page”.

Further Documentation

Functional Specifications and Technical Specifications serve to embody the application in a prose-like instantiation. In particular, the functional specification must accurately reflect the modules and interfaces to the system. This is particularly useful for Quality Assurance to provide an independent measure of the success of the project. Technical Specifications are often embodied directly within the code. Various tools can be used to extract documentation directly from the living code to ensure that it is easy to keep up to date.

Coding Standards

Whatever the development environment, it is important to adopt and adhere to specific coding standards. This includes specifics of formatting and commenting code, but can also include specific design patterns.

Quality Assurance

It is useful to have a separate quality assurance program to provide an independent analysis of the project to ensure that it has lived up to its stated design goals and functions according to specification. h4. Iterative Development Many problems are too big to be developed all at once. When working with stakeholders, it’s useful to prioritize requirements and do a “phased” implementation starting with a subset of the product features. Further requirements can be handled in an iterative approach over the course of time. The Scrum development methodology embodies most of these elements. The principal is to organize development using fixed-increment (typically 30-day) phases. Requirements are prioritized and analyzed for inclusion at the beginning of the phase (called a Sprint). Short daily meetings are held to communicate progress from the previous day and goals for the next day and to identify issues that are in the way of achieving these goals. This results in a system that starts up quickly and achieves added functionality over time. The Scrum process can be used for both documentation and development efforts. For a good description of Scrum check see

Gregg Kellogg