A Matter of Perspective
I was recently working with a client that develops and deploys large-scale, complex solutions. Their product consists of custom and COTS hardware, embedded software, networks, and server-side installations. Read more
Divide and Conquer
In the ideal situation, the process of software development should consist of a series of appropriately selected steps, each of which clarifies some aspect of the system as you proceed from inception to delivery. Done properly, there should be no “and then a miracle happens” steps along the way, as can occur when you dive into the code right after throwing together some concepts on the back of an envelope. Read more
Design as Translation
Put together a piece of IKEA furniture, and you can’t help but marvel at the thought that has gone into the design – they are continuously managing the balance between style, functionality and price, all in a package that can usually be constructed only with the provided hex key, sometimes without a look at the manual at all. While you can certainly find more stylish pieces elsewhere, you will generally pay quite a bit more, and it almost certainly won’t fit in the trunk of the car. Read more
Designed Testability
The greatest opportunities for saving time and effort in any endeavour can usually be found in the activities that are most repetitive. In software projects this is often the testing stages, especially as the lifespan of systems is increasing, and more teams are adopting practices such as daily builds (that need to be exercised) or eXtreme Programming (where the goal is for the system to be live as much as possible). If a retrospective is the most powerful approach for improvement late in the project lifecycle and change management is a strong in-progress activity for control, designing testability into the system is one of the best activities to perform early on to reduce cost. Read more
Design for the Ages
The design phase of a software system, assuming it is done at all, is your major opportunity to ensure that you translate the system needs into a product that can adequately address all of those needs in a predictable fashion. If this phase is neglected, the likelihood of achieving the projects goals diminish dramatically – there is no cohesive architecture on which to place all the required functionality, there is no coordination in design that simplifies and streamlines the development, and there will be surprises downstream that threaten the completion of the project itself. Done well, a design takes into account the past, present, and future of the product. Read more
Building an AMO
Many organizations today are coming to the realization that they can leverage their expertise and historical knowledge for even greater value. They build PMO’s that serve as a center of project management excellence. The PMO can serve as the focal point for ensuring that projects are consistently managed and that the organization learns from past experience. In addition, by extending their oversight beyond projects that simply create the traditional products the company sells, a well developed PMO can act as the group that implements the strategic vision of the organization. Read more
Thorough Design
In teaching an undergraduate course that touches a broad array of topics in software development (from estimation to design to QA to CM to test), I find the greatest challenges to be that few in the class have ever experienced software development in industry, where these topics evolve from theoretical to critical. In an environment where many projects can be accomplished within the confines of the development environment, it can be difficult to appreciate the need for all these ‘overhead’ elements. Read more
Deciding How to Test Early, Twice
To develop a software product, there are a couple of things you should do to help ensure it gets done as expected (actually, there are quite a few things you need to do, but this is a brief missive). You need to decide how to test early, and decide how to test early. Read more
