Here’s the abstract:

Information technology holds tremendous potential to help consumers and firms make more sustainable choices by providing information at key decision points. As one example, there are a number of software programs that help calculate and summarize environmental metrics for various products and processes. Surprisingly, while many printers are moving into the IT arena, the technology has not been fully utilized. For the most part, there is a lack of knowledge on the part of the consumer on the sustainability impacts of their communication decisions. Thus, this paper outlines a decision tool, presented to the consumer as they make a print decision, which estimates the energy consumption of printing a given document by analyzing the user’s requirements for the print job, the printer selected and the corresponding life-cycle criteria for these elements.

If you’d like to read more, here’s the link to the paper in PDF format. I’ll be uploading the other major component of this work (i.e. Java code) in the near future.

(click for a larger view)

Sans the blood and the tears, it was quite an amazing ride. Traveling to Rochester, NY, spending 2 years at RIT and meeting all the awesome people I met along the way, is one of the most salient experiences of my short life. And to think I was morose and utterly worried because I didn’t know whether I was going to get a scholarship almost three years ago. It’s incredible what persistence and an optimistic mindset can do.

With the arrival of the certificate, this chapter of my life is officially over. It’s now time to move on and look for bigger, more difficult challenges. Up, up and away!

If you don’t have enough time to watch the whole thing (Aha! That’s a clear indicator of how poorly managed your time is!), here’s the presentation’s gist according to yours truly:

• Your desktop (i.e. your working environment) must always be as organized as possible. The more clutter you have, the worse off you’ll be.
• Multiple displays (i.e. monitors) are a must. In terms of sheer productivity, an extra screen goes a long way.
• Master your inbox. Do not let your inbox, and its unceasing influx of messages, waste your precious time.
• Avoid interruptions. If you’re working, you’re doing just that. Nothing should come between you and your working hours.
• Monitor yourself. You should be able to answer this simple question: what did you do 3 days ago at 3:45 PM? A calendar is a must-have.
• Procrastination is really expensive. Waiting until the last second to work on that assignment or project is more expensive than planning ahead.
• Kill your TV. Enough said here.

These are, of course, just a few of the most important pointers you can extract from Randy’s eloquent discourse. I suggest you watch the presentation in its entirety. That would be time well spent.

Take a look at one of the public maps submitted by one of the site’s members (What Smart Students Know – 12 Principles):

Source: Mindmeister’s public maps (click on the picture for a higher resolution)

If you have never tried out mind maps, make sure you do so the next time you are explaining any new subject to a novice. I have noticed complicated subjects tend to be easier to grasp when you present them with the help of graphic elements. A picture is worth a thousand words, right?

NOTE: The paper’s tone was rather informal (i.e. not academic) because the professor encouraged “open” and “brutally honest” communication in class. He wanted our work to be clear, concise and to the point. He was not fond of bombastic verbosity or the “stiffness” of scholastic vocabulary.

—

We are usually accustomed to hear and read about TQM (Total Quality Management) in other areas but software development (SD). We normally run into the concept in one of our business courses or when somebody blurts it out during a meeting at work. However, TQM’s notions can be easily applied to SD management in order to increase productivity and reduce the amount of bugs introduced in the final product.

Let us succinctly review TQM’s main aspects (i.e. customer focus, attention to process, continuous improvement, measurement and analysis of data, human factors, management and leadership) and how they relate to software development.

CUSTOMER FOCUS

One interesting characteristic of every modern quality theory is the preponderant role the customer plays in the definition of quality. Simply put, the customer determines what quality is. TQM is no exception to this principle. [Carroll, 1995] Similarly, software developers are also on the lookout for better and more efficient ways to achieve maximum customer satisfaction.

Personally, I have noticed most software engineers (at least the vast majority of the ones I’ve met) concern themselves with what customers, both internal and external, have to say about the product. Do they like our software? How do we know? Conversely, do they detest our product? If so, why? How can we improve our software? Feedback, whether rants or positive comments, largely determines what goes in or out of the next release.

Naturally, internal communication becomes another important aspect. The ability to keep everyone in the team on the same page will go a long way towards higher levels of customer satisfaction:

TQM requires cross-functional teams to encourage communication and business understanding; working with staff from outside the IS function means that system developers gain a greater understanding of the business problems which need to be solved by information systems (Mathieson and Wharton, 1993; Tobin, 1990). [Carroll, 1995]

CONTINUOUS IMPROVEMENT

A salient theme discussed in every other managerial meeting, and one that has also found its way into the software development realm, is the concept of continuous improvement. TQM’s definition of continuous improvement is remarkably concise (dare I ask, recursive?):

Continuous improvement (or kaizen) is a continuous process of making improvements, typically by small steps. In Japanese, kai means to alter and zen means to make better. [Brandon, 2006]

Despite its seemingly easy definition, continuous improvement is one of those gray, murky areas in software development. How do you know you are effectively improving your build and deployment processes if you tweak them a little? What metrics are in place to feasibly estimate improvements over a long, or short, period of time? It all boils down to a simple, yet crucial, statement:

Quality planning and delivery is an iterative process. [Phillips, Joseph & Luckey, Teresa, 2006]

So, when in comes to process improvements (both in TQM and SD), the approach yielding the most results is encapsulated by the following remarks: measure, measure, measure, iterate, iterate, iterate, ad infinitum!

HUMAN FACTORS, MANAGEMENT AND LEADERSHIP

The value of a good manager is immeasurable regardless of the discipline we are talking about. SD is not an exception to this conspicuous canon:

Management must lead, not punish. It is manager’s job to help MIS staff do a better job and create a better system. Project managers must be trained in basic interpersonal and analytical skills. They must have a solid understanding of statistical process control. They should know that in any software development team whose performance is in statistical control, half of them would always be below average. They should focus on those members whose performance is out of statistical control. [Chen, 2000]

Just as TQM’s concepts undeniably portray, the role of upper management in achieving higher quality standards lies within a single concept: leadership. Software engineers, just as everyone else doing any kind of creative job, need to be particularly motivated in order to achieve their utmost potential.  When the leader, instead of just “the boss”, fully understands the technical minutia of SD, cares about the well being of his/her engineers and proactively fosters an environment conducive to innovative work, there is greater room for involvement and collaboration among team members (necessary traits of every team in today’s fast-paced IT industry).

A BIGGER PICTURE

Overall, TQM’s concepts and principles are certainly applicable to software development. Nevertheless, because it was initially conceived to appeal to a broad range of industries, other theories were created after TQM to specifically support software development and maintenance. Refer to the following picture for a few examples of new quality theories and their relevance in SD/IT:

Source: Project Management for Modern Information Systems, 2006

What has your company done to accomplish higher levels of quality in your software development processes? Has TQM meant anything to you and your organization? If not, has any other quality policy been used to help you cope with bugs and maintenance costs?

BIBLIOGRAPHY

Brandon, Dan. Project Management for Modern Information Systems. IGI Publishing, 2006.

Carroll, Jennie. The application of total quality management to software development. Information Technology & People. Vol. 8, No. 4. Department of Information Systems, Monash University. Australia, 1995.

Chen, Houn-Gee et al. Total Quality Management in Software Development Process. The Journal of Quality Assurance Institute, Vol. 14, No. 1, January 2000, pp. 4-6 & 35-41.

Phillips, Joseph & Luckey, Teresa. Software Project Management for Dummies. John Wiley & Sons, 2006.