I need to do some design work soon, and it has me thinking about the design process. What’s the best way to go about designing software? The answer can vary for different organizations. Recently I took the “Software Design Techniques” class from PSU, which offered some solid tips. Here’re my general recommendations:
Set Some Goals Upfront
Eventually you’ll produce a design. Maybe you’ve produced some very professional UML docs or a slick data-flow diagram. Perhaps you’re like me and have scribbled some circles on a whiteboard and taken a picture of it with your phone. In any event, the next step will be to ask: “Is this any good?” To answer that question you’ll need to have established what “good” means for this project. Set some goals at the beginning for what your design should achieve. Keeping them in mind during the process will help.
Know Thy Stakeholders
It can be tough to produce software that pleases everyone. Stakeholders often have conflicting desires. Product managers want it done fast, QA wants it to be easily testable, the ops team wants the deployment to be hassle-free and the end user is asking for an intuitive UI. Your fellow engineers may have several technical priorities. The challenge is to try to consider several perspectives as you proceed. Hopefully your product/project manager can help you prioritize requirements and balance conflicting stakeholder needs.
Prepare for the Likely Changes
Let’s pretend you just produced the best design ever for a billing system. You’re quite pleased with yourself. Then, one month after release Bob from sales rushes into your office and says, “We need to import billing data from Company X… by next week!” Ideally you’d have already talked to sales and known that the Company X integration was imminent. It’s a great mental exercise to make a list of the top “likely changes” to the system that you and others foresee. Again, your software can’t do everything and the architecture won’t respond to all requests with equal grace. However, you should know the company’s priorities for future development, and those things shouldn’t require a full rewrite of the system.
Get it Reviewed
I mentioned before that code reviews are very helpful. Reviews are great for design products as well. Designing by committee isn’t fun, but this is a little different. In a design review you present a fully baked (you hope) plan to some peers and solicit their feedback. Maybe they’ll have tackled a similar problem last year, failed miserably, and found an open source tool that solves everything.
On a team practicing some form of Agile development, you may be asked to produce a design quickly and get on with it. It’s important to at least cover the basics if you want to arrive at a design that’s somewhat sustainable and doesn’t disgust the new guy you’ll hire this fall. Do you have a sure-fire design tip or pet-peeve?
