Practical Software Engineering

In Living with Constraints, I touched on a topic that is on the mind of software people: managers and developers alike. The time constraint, also known as “The Deadline” is of particular angst for some technical people.

Many people have a fear of deadlines. They are as frightened by them, as they are of speaking in public. For developers, the mastery of both can be a critical success factor. For managers, they are a survival skill.

What happens if you have a problem with deadlines? Maybe right now you have difficulty meeting the deadlines thrown at you, and you have given up on being able to meet them. Not meeting deadlines can be detrimental to your business and your career. So, how do you get out of this?

The age old advice is right on the mark: start out by setting small deadlines that you can meet. Get early wins. The only way you can get better at meeting deadlines is… by actually setting and meeting deadlines.

Along the way it helps if you remind yourself as to why are you doing this: you are getting better at meeting deadlines, because deadlines are nothing more than commitments. The world runs on commitments. Both your business and personal life depend on commitments. Your ability to succeed depends on your ability to make and meet commitments. Other people count on your output. You shouldn’t let them down. And you count on commitments from others. Once the chain reaction of missed commitments and deadlines starts, the endeavor can spiral out of control.

What is a good first commitment? Select a deliverable that can be done in 30 minutes or less. Make a commitment to yourself at the beginning of the day that you complete the work by the end of the day. That’s your first deadline. Here is an example: “I provide feedback to John on the white paper by 5 pm today.” Repeat this for a week.

Once you successfully meet your deadline every day for a week, then set yourself a slightly more ambitious goal. Make the next deadline one that involves between 5 to 10 mini deadlines to deliver on a more complex deliverable (requiring about 5 hours of total work). Then work yourself up to 20, 40, 50 hours of commitments involving many intermediate deadlines. Meet each one, and see your confidence grow.

As you set and meet commitments the word will get out that you are a person to trust with projects. You will become every more successful. And you will see your career take off.

______

PS: The Deadline is a book of fiction by Tom DeMarco. The author illustrates many issues surrounding software development. The main character of the book, Mr. Webster Tompkins, the project manager, sets up three teams for each product to develop the same system with different methods. Make time to read it.

You heard of Wikis. You might be using them daily. They are everywhere you look. Unfortunately, quite a few of them are not as useful as they could be. Over the years many of them became dumping grounds for page after page. Now it is almost impossible to figure out what those mean or how they are related. Other Wikis languish for lack of participation. How can you make your Wiki work better for your group of collaborators? Make the Wiki tell a story!

How to turn your Wiki into an engaging story? Follow the advice from story tellers:

1. Decide on the story you want to tell,
2. Create a story line that engages your audience,
3. Tie your pages together into a coherent whole.

1. Decide on the story. What’s the purpose of your Wiki? Is it for a project? Or just to keep track of your ideas? Or to support a product? Whatever it might be, decide on a story that you’d like to tell and build a plot for it. The plot should include the main story line and will include multiple secondary plots. Once you have the plot, write the summary of the story on your starting page in the Wiki.

2. Create a story line. All good Wikis tell a story. Be it the story of a project or of something else. They draw you in and make you click on page after page because they have the information that you want. And where the information is missing a good Wiki compels you to add the missing paragraphs and pages to make the story complete.

3. Tie your pages together into a coherent whole. Decide on a starting point for your Wiki. This is pretty easy since all Wikis have a Home or Main page that serves as the start. As you are writing the “plot” of the story, lay it out across multiple pages, but always make sure that you link one page to another. Before linking to a lengthy “sub-story” in your Wiki, include a summary of that story, and let the user decide if they would want to follow on that link, or just skip to the next chapter.

Practice, practice, practice! Just like with anything else, you’ll get better at writing if you practice. The book Writing the Natural Way by Gabrielle Rico, Ph.D. can help.

Back in the second half of the eighties I have been using some agile practices, but we didn’t call it agile back then. We regularly pair programmed because my friend and I shared one computer; neither of us wanted to just sit and do nothing. Our workflow also included writing test programs (much like unit tests today).

In the early nineties I read “Managing the Software Process” by Watts Humphrey. This was my first introduction to the CMM. I found many of the concepts valuable, even though, I was working alone. The knowledge presented was applicable to my software engineering work, with the necessary adjustments for a group size of one.

Many years later, after the agile movement got traction, I was surprised that so many people had such strong feelings about the CMM given my positive experiences with it. In time I understood that there were many organizations that got their CMM implementations off track. They focused on paperwork, instead of changing the day-to-day work of practicing software engineers.

After over two decades of CMM & CMMI and over a decade of agile, the software engineering community is realizing that a sensible strategy is to integrate the best of both worlds. A recent paper published on the SEI website by Hillel Glazer, Jeff Dalton, David Anderson, Mike Konrad, Sandy Shrum urges us to do so: CMMI or Agile: Why Not Embrace Both! It seems that I am not the only one thinking so. Scott Ambler wrote a review of the paper at DDJ called: Agile CMMI: Complimentary or Oxymoronic? Read the paper, read Scott’s review, and decide for yourself.

If you are part of a volunteer organization, you know that the organization needs a website. You may also know that it is difficult to find a webmaster for the group. Most folks don’t know HTML, so you need a website that anybody can edit through a browser. Here is how you can set one up quickly for very little money and without much technical knowledge.

1. Buy a domain for your group. I volunteer at the IEEE Technology Management Council, Central Texas and Austin Chapter. We bought the austin-tmc.org domain from GoDaddy.com.

2. Install Google Apps for your domain. Select the Standard Edition (free–ad supported, as of Jan 2009). Go to the Google Apps site, follow the steps described in the documentation on installing Google Apps for your domain. They have specific steps for domains bought from GoDaddy. You will have to go back to your GoDaddy control panel to add CNAME and MX entries to your domain.

3. Add users to your installation of Google Apps. While you are waiting for the apps to be setup for the domain, you can already start adding users. Create a username for each of the volunteers helping out. In my case this is usually a group of 10 to 20 people.

4. Create a Google Site for your website. Ours is called web. We also create a site for volunteer use called Wiki.

5. Using the Google Apps control panel installed for your domain (you can get to it by following a link in Mail, called “Manage this domain”), go to the Dashboard. Next click on Site Settings, and Web Address Mapping. Setup a mapping for www to be mapped to the site you created in step 4.

That’s it. Now you have a website installed for your domain. If you need a mailing list, go to Google Groups and set one up. You need a GMail account for creating a mailing list.

Happy volunteering!

This week at Agile Austin the conversation veered toward a familiar topic: each problem is different therefore we cannot apply the same process to them. We, software developers, want to believe this. Why? Because this can be used as a convenient excuse: we don’t have to follow a process if all problems are different. After all, we are on a quest to find the one true process that fits all programming problems, right?

Reality is more nuanced: when we look at each problem in its entirety, then indeed each problem is quite unique. When we divide a big problem into a series of smaller problems, then many of the smaller problems turn out to be run-of-the-mill everyday problems. We have seen them, and we have processes (not necessarily written processes) for solving them. Maybe we need to tweak a processes slightly because of a minor variation, but we can comfortably identify the pattern and follow the associated process.

A few of the constituent sub-problems, mostly the ones that provide the unique value proposition of the application, require unique treatment and attention. For these we need to create new processes. These are processes that are custom fitted to the new problem. These, however, are a small fraction of the overall problem.

It might help if we think in terms of process building blocks. Some of these building blocks are already available. We only need to create some new processes to custom fit a the new parts of the problem. As early as 2002, in my talks I have been proposing the following:

1. The problem needs to determine the process required to solve it.
2. A team that worked on a few problems together already has some processes that they used more then once. Let’s call these software process building blocks.
3. When faced with a new problem, the project team assembles the exact process that solves the overall problem.
4. For the brand new parts of the problem, the team creates new processes.

The “One Right Process” that solves all problems doesn’t exist. A “process framework” that contains concrete processes for “smallish” problems can be useful. Based on the framework we can create an instance of a process that fits the problem we have to solve. Then, we have to follow the process that we just created to solve the problem on hand.