I’m a firm believer that everything can be demoed. Your client is paying you big money to define that API, refactor that service layer, set up those build tools, write up that WSDL, define test cases etc., and thus it should be demoed. Telling him/her that you can’t show him what you did in a fortnight doesn’t show much respect to that fact. How would you feel if the extremely expensive painter you hired, tells you after 2 weeks: “we worked really hard, achieved much but we can’t show it to you”. I wouldn’t be happy and very curious to know what the hell they were doing all that time.

If there’s boring stuff to show (like 10,000 lines of XML configuration), at least show what we now can achieve or explain it in a schematic, visual way. Here are some ideas.

Demoing webservices:

  • Throw together a quick UI, which might just become the test tooling you so desperately needed (but didn’t take time to write).
  • Show some JSON or XML, mark the new stuff, explain that and how it relates to the rest of the system.

Demoing architecture:

  • You, calling yourself an architect, should be able to explain your work to less-technical people. Period.

Demoing refactoring:

  • Show improved Sonar (code quality tooling) metrics.
  • Outline what can now be achieved more easily.

Demoing test effort:

  • Show improved test coverage.
  • Explain the number and sort of bugs found.

Demoing requirements:

  • Show some documentation on the screen, describe the requirements in a high-level way.
  • Do a play, exercising the user story that has been worked out.

Demoing a WSDL:

  • Generate a SOAP client in a visual SOAP testing tool.

It might not come easy and like everything, requires practice and preparation. Coming up with an appealing way to demo that tediously boring piece of work requires creativity and out-of-the-box thinking. Use LEGO (I did), play a game with the attendees (I did), visualize it on a whiteboard (I did) or do a little play (I did not, yet…).

Demo everything.