Demo Daze: A Post-Mortem On A Successful Demo
I’ve been working pretty hard the past two weeks or so, cobbling together a demo for a customer based on a healthy chunk of the BEA product line-up: WebLogic Portal (WLP), WebLogic Integration (WLI), AquaLogic Data Services (ALDS), and AquaLogic Service Bus (ALSB) — all built using our IDE, WebLogic Workshop.
Oh, and we threw in a partner’s product — CollabraSuite.
I list the products because:
- The sheer number of products involved will give you a sense of the complexity involved. I’m going to make a point about this in a moment…
- I’ve written some really shitty software under duress in the past. My friends from my last job and I often talk about some of the “interesting bits” they’ve found in code I wrote before I left after working on the software equivalent of The Bataan Death March.
- And, yes, I am a sales engineer, so I’m (sub)consciously always trying to make sure folks appreciate my employer’s warez.
Okay, so here goes…
The big epiphany I’ve had while building out this demo is that there are specific “best practices” that tend to get tossed out o the window when writing demo code, or even writing simple test harnesses, and “throwaway, one-time use” code.
Obviously, it’s a fallacy to believe that any code is only used once and then thrown away. Someone will ultimately stumble across your work and attempt to extend it or customize it. Of course, before it even gets that far, when developing a sufficiently large and complex application, you’ll find that taking a measured, systematic approach to developing an application pays dividends because, as you look at your own code, you won’t have a WTF moment.
So, here’s a brain dump of what worked to make writing this demo fly…
- The first step? Whittle down the requirements and come up with a coherent plan. In the case of a demo, the plan is turned into this:
- Determine which products are a good fit for the demo.
- See if I can reuse some existing demo code from other sales engineers (SE) and product specialists.
- Scope the problem to fit the timeline. A demo’s timeline can’t slip.
The first week was spent doing those steps in parallel — I had thoroughly investigate the pre-existing demo code I had chosen to “extend”. This took about a week. I resisted my typical urge to dive in, ego first, and begin coding. I also spent that week making sure I knew what each product could do in the context of the final application. I had been given a list of features to show off (re: requirements). The folks driving the demo were flexible enough to give me room to wiggle. For example, some products were left out of the demo because I am not familiar with them. So, on an aggressive timeline, there simply wasn’t going to be time for me to learn a product well enough to build out a demo that leverages it in a substantial way.
- The first week wrapped up with me making a decision: I was going to follow the “best practices” I pitch to my clients all the time — even though I’d be running on a single server. At the time, I was donating my Sun W1100z box to the effort, since my demo architecture involved running three separate WebLogic domains: one for portal, one for the service bus, anid another one that contained data services and workflow. Of course, as any good sales engineer will tell you, it isn’t common for customers to poke around in the source code of a demo, so there can be a lot of MacGyver‘d stuff in a demo — lots of wire, duct tape, and pre-chewed bubblegum holding it all together… all possible because folks aren’t going to kick the tires and look under the hood.
That said, this demo was complex enough to merit splitting things up for three reasons:
- I was planning to enlist some co-workers to pitch in and help out… So keeping things compartmentalized would make splitting up the work even easier.
- I could then build & test components (data services, web services, and the UI) using a WebLogic application that was laser-focused on just that type of component. Case in point — we had a set of data services built out using ALDS. I layered web services on top of those data services. While I could simply test the data services from the IDE directly, it was extremely handy in debugging later to have test harnesses based on the web services that would front those data services already in place. I also could create a set of test cases that would pull double-duty later in the project — because once I put the service bus in front of those web services, the same SOAP message bodies could be sent to the proxy services to be routed to the data web services. This meant one test case could actually be re-used to test both the data web service and again to exercise the routing of the service bus.
- It reflected reality. I always tell my customers to build their applications this way — why shouldn’t my demo code reflect that philosophy? This is called “eating your own cooking”. If you do it poorly, it’s called “eating your own dog food”.
- The second week began with me digging deeper in to the pre-existing demo code which was really focused on AquaLogic Data Services (ALDS), a product that I am admittedly not an expert in. I’d rate myself (well, when I started this project) as being “conversant” with it, but not an adept by any stretch of the imagination. I was fortunate enough to have a product specialist in my office who I could leverage, but my time with him would be limited, and I was told up front not to expect him to provide direct code support… so any major changes would probably be my responsibility.
So, as I dug into the demo, I found that it was fundamentally very solid… very data-driven. However, what we lacked was a lot of test data. And given the complexity of the underlying data sources (hey, it has to be complex — our product shows how we take a bunch of data sources and do a mash-up on them to create a more holistic view of the data — which is especially useful for systems-of-record). So we really had enough data to show one use of the application, with a workflow involving two different users so that we can show off data redaction (which is the ability to remove specific bits of data from data returned from our services if the requester is not authorized to view it).
That meant test data was a possible limiting factor. I figured that the amount of time we had to present the demo meant that we really did not need a lot of test data unless we wanted to make the screens look a bit busier… which of course, makes it look more polished, like a real-world application.
The big surprise was that the user interface contained a lot of hard-coded ties to the test data… nothing too evil, but it presented some minor headaches sorting out how to do the decoupling of the web application (portlet) from the data services. In the original demo, because they lived in a single application running in a single domain, they were tightly coupled. This demo would mirror a more common scenario in a Service Oriented Architecture — the two would be running in separate domains.
- The lion’s share of the work was ripping apart the UI of the original demo to do that refactoring, and making the HTML consistent with the look of the new demo. While the original web application was very colorful and could go crazy with screen real estate, I had to not only change the look, but change the “flow” of the web application so that parts of it could be split out in to separate portlets (such as a worklist).
- Add eye candy. The sexiest feature? Well, I stumbled across a cool extension to Wordpress (my blogging software), called GeoPress. A link from the author’s page led to a site with tutorials on how to leverage Yahoo! Maps from your own website. Watch out, Google Maps… Yahoo! is in your rear-view!
Now… the painful part: the pain, and the reason for my disappearance from the world since last Friday has been because the HTML coding became really tedious because I had to manually cull what was needed from pages created using tools (and no, it wasn’t Workshop for your haters out there ). As a result, I had to do a lot of tedious ripping & pasting, while trying not to offend the CSS and HTML gods by committing atrocities in my web application.
I also experienced a hard disk failure (!) courtesy of a new Seagate 200GB drive, the effects of which were mitigated by the fact that I kept backups of EVERYTHING on a CD-ROM (because yes, I am that paranoid). As disappointing (and embarassing) as it was to not be able to walk in the door on Monday morning with everything chugging along — it was still pretty sweet to pull the backup from CD and get evertyhing up and running with about two hours of effort on my laptop. Ultimately, we ran the demo on Wednesday using just the laptop, and it performed admirably.
(I am still lobbying my boss to get us some new, sleek laptops… although I already have one of my own on the way!)
The reward? Well… as I was walking alone down the hallway to leave the area, one of the customer’s employees told me it was a fantastic demo and that I did a great job.
That makes it all worthwhile…
Leave a Reply
You must be logged in to post a comment.