Real-Time Problem Detection in Software Development

[article]
Summary:

 

 

In designing and developing software, it's usually cheaper to prevent problems from ever occurring (by making a decision at design-time) rather than patching them as they happen (by a last-minute fix after deployment). It's cheaper (and substantially less stressful) to design a system to handle thousands of concurrent users rather than trying to diagnose and fix a system that mysteriously breaks in production under heavy load.  But detecting problems in real-time is a useful skill in many professions, including one as different as recording audio books.

I used to work as an audio engineer and my job was to record audio books (also known as books on tape). If you've never seen a recording session, it's a fairly simple affair: a reader sits in a soundproof booth with a microphone and reads a script. Outside the booth, an audio engineer operates the recording system while the producer coaches the reader to get their best performance. When the reader misreads the script or their stomach growls mid-sentence, the engineer tells the producer who decides if the passage needs to be re-recorded or not. It is a job that involves real-time problem detection; it is cheaper to correct failures as they happen, rather than calling the team back a few days later to re-record some flubbed sections.

Real-time feedback is helpful in software development if you can eliminate the stress felt from making a mistake.  Here are some ways to get real-time (or near real-time) feedback when writing software:

 

  1. Unit tests and Test-Driven Development . Tests provide feedback that can indicate if a change to the production code has broken your application. By following TDD's formula of working in small incremental cycles of test-code-refactor, you can detect problems as they happen. Some tools even run tests in the background as you change your source code and monitor for failures as they are introduced . For some examples, see autotest for Ruby and Infinitest or JUnit Max  for Java.
  2. IDEs and static analysis . By using tools such as IntelliJ IDEA that analyze your source code as you write it, you can detect defects before they're released. IDEA ships with detectors for many known problems (such as null dereferences, etc.) but you can also define your own set of rules to enforce any project-specific design standards. For example, I worked on a project that had rules about how to organize the code to minimize external dependencies.  To enforce these practices, the IDE provided real-time feedback if the external libraries were ever imported into off-limit areas of the application.
  3. Continuous Integration servers . By setting up servers which wake up on every commit to the version control system and run a set of builds and tests, we can verify that every commit yields a working product. The length of time to get that feedback will vary based upon the length of those builds, so this is more like "near real-time" feedback.
  4. Pair Programming . When programmers write code together in pairs, they get immediate design feedback from each other. In addition, working with a pair is another way to enforce team standards; when you have someone working with you, you're less likely to cheat on some practice or principle.

 

What other forms of real-time (or near real-time) feedback do you use in your work?

 

User Comments

2 comments
Anonymous's picture
Anonymous

One important attention that has been missed is involvement of key end users who are supposed to use the application. Their continuous feedback is very very important and valuable during product development. This will lead to least hiccups during the implementation, UAT and project sign-offs.<br><br>These are my 2 cents.<br><br>Best Regards,<br> <br>Jaideep<br>

February 9, 2010 - 2:42pm
Anonymous's picture
Anonymous

Yeah, I second to that. In software development, one important factor that should always be considered is the key end user and the level or the type of people that will use the software you are developing. Forgetting this matter is one big NO NO n this field.

March 11, 2010 - 2:25pm

About the author

Daniel Wellman's picture Daniel Wellman

Daniel Wellman is a technical lead at Cyrus Innovation, a leading agile consultancy based in New York, where he leads development projects and coaches teams on adopting agile software development practices. Daniel has more than ten years of experience building software systems and is an expert in agile methodologies, object-oriented design, and test-driven development. Contact Daniel at dan@danielwellman.com.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!

Upcoming Events

Sep 24
Oct 12
Oct 15
Nov 09