
4,364 articles on Engineering.












































In January 2001 two Java tools crossed Refactoring's Rubicon. Refactoring in Java now has serious tool support

Why we need methods that assume software should be soft and open to change.

You can use metadata based approaches to remove the pain from tedious data oriented tasks.

Guidelines on when to make a new user defined type (or class) for values.

In late June over a hundred people gathered on the Mediterranean island of Sardinia to take part in the XP2000 conference to discuss Extreme Programming (XP) and other flexible methodologies.

One of the attractive things about XP is that it gives quite definite statements about what you should do to be doing XP. Furthermore that set of practices is carefully designed to fit together. Taking anything out has serious consequences. Yet one of the principles of XP and other agile methods is that they be self adaptive: that is you should change the process as you are developing the project.

Many modern languages make a distinction between public and private features in a module. A distinction that doesn't get made so often is between public and published features: and that may be a more important distinction.

It’s hard enough for software developers to write code that works on their machine. But even when that’s done, there’s a long journey from there to software that’s producing value - since software only produces value when it’s in production. he essence of my philosophy to software delivery is to build software so that it is always in a state where it could be put into production. We call this Cont

Why you shouldn't write a lot of documentation.

My thoughts on the role of analysis in OO projects..

What is the point of drawing up UML Models?

What does it mean to have a standard UML, and why the standard doesn't standardize as many things as people think it does..

Clear code is good, but should you sacrifice clarity for testability?

A common part of encapsulation, particularly with object-oriented systems, is hiding data structures. Yet it's also common to expose much of this data behind data access routines. In this column I cover some guidelines for writing data access routines. However don't forget that if you can leave the data hidden, that's usually better.

One of the first lessons I learned was to always keep user interface code separate from anything else. Not just is this still good advice, it's surprising how often it's forgotten.

Craig's spot in the column looks at the importance of the Open-Closed principle and Protected Variation, and why Parnas's information hiding is more than encapsulation. He also gives some tips on ways to implement a protected variation.

Thinking about how to visualize and reduce coupling.