Michael Scharf

Why engineers are "immune" to marketing messages...

On Friday, I read Rob McCammon's blog entry titled The Right Requirements Plus Good Advice Result in Better Solutions Faster. The message is "don't take requirements literally, figure out what the real problem is and find a solution for the real problem (not the solution implied in the requirement). Use the help of people that look at it from another perspective". I could not agree more! But the real interesting thing is the message behind the message, something about marketing in general. But before you continue reading, read Rob's original posting, I want that you read it unbiased.

The message behind the message is a message about how marketing works. I read the blog two days ago, and the only thing I remembered was: "why did Rob need a neighbor to see a generator was the best way to go?". I know Rob. He is a really bright guy. So, why did he need his neighbor? Ok, I'm biased. Rob is a marketing guy, and we (engineers) don't trust marketing. We want to know the "truth" behind the marketing message. Therefore, we read marketing messages more critical than other messages. Even if it is true (that he needed his neighbours help), it sounds to me like he tweaked reality a bit to make his point. This weakened the true point of his message (that we have to find the truth behind a requirement and that we need the perspective of others). I could not hear it. I got sidetracked.

So, the message behind the message is that marketing guys(*) "optimize" their messages by "tweaking" reality. But engineers want the real truth. We simply don't believe in the slick marketing messages. We are a hypersensitive when marketing is "tweaking reality" to make the point. Even if the base message is true, the "tweaking" decreases its creditability and authenticity. This is the reason why many engineers are "immune" to marketing messages. We don't trust the entire message if we have the slightest doubt on one of the sub-messages.

There's another incarnation of the same problem in Robs posting. It is the use of buzzwords in the title: "The Right Requirements Plus Good Advice Result in Better Solutions Faster". What is "Right", "Good Advice " and "Better Solutions Faster"? It sounds to me like flashy marketing buzzwords. They have no value to engineers... We ignore it, similar to flashy animated advertisements on web page, known as Banner Blindness. We simply don't see it, we don't click on it.... The more you make it flash, the less we see it.

I don't feel good dissecting and criticising Rob's message, but it is such a great example of a marketing message. In some sense, I applied the advice he gave us in his blog entry. The requirement is to "effectively communicate with the community". The implied solution is "write slick blog entries". The method to come to a better solution is to use the expertise or perspective of others (in this case engineers) that are complimentary to your own. The shift in perspective is that slickness does not matter, its trustworthiness. The solution is to tweak the massage less and cope with the imperfect reality.

The real irony is that I have been struggling with this blog entry much longer than any other entry I ever wrote. I tried to tweak the words to get my point across. It's so hard to "do it right", especially if your blog is supported by the company....

(*) Disclaimer: When I say "marketing guy", I don't want to discredit any person working in marketing. Especially not Rob. I refer to the concept of what engineers think when they refer to "marketing guys" or people creating "marketing messages". Maybe the real problem is the prejudices I (and maybe some of my engineering colleagues) have about marketing. But that's another story, and some "marketing guy" or "engineer" may comment on this. Let's get some "blog-wars" started ;-)

Is footprint still important for desktop applications?

I just read Tomas' blog entry titled Is footprint still important for embedded devices? His answer is a clear "Yes." Well, what about desktop applications? Why the heck are desktop applications so slow and memory-hungry?

Like Tomas, I bought my first computer in the late Seventies. I did a vacation job for a month and bought the computer with a friend (50/50), because it was so expensive. It was a Commodore Pet 2001 with 8kb of RAM. Unlike Tomas, I programmed it in Basic (Assembly did not attract me). One of the first programs I got running was Joseph Weizenbaum's ELIZA. I actually got a listing and I typed it in and modified it a bit. From then on I was fascinated by the art of programming: Modula-2, C++, Python, Java, showing a trend in the direction of higher level "more expensive" languages and systems.

Ok, back to the question. Let's look at IDEs as an example. For some reasons IDEs always "stress the desktop systems." 20 years ago I used EMACS. At that time people said EMACS was an acronym for Extended Memory And Constantly Swapping. With SNiFF we had the same problem. And today, Eclipse stresses our desktops.

Yes, careful design, better algorithms and data-structures can improve performance and footprint, but don't think desktop application developers don't already do this. The real problem is somewhere else. Identifying and fixing real hotspots is easy. In all those systems, quite some effort was put into performance and footprint improvements. However, it is incredibly hard to optimize complex systems with no real hotspots. If you use a memory analyzer or a profiler you'll hardly find hot-spots that contribute more than 5-10% of the overall footprint. There are usually higher priority tasks during development than optimizing a 5% problem.

Let's look at Eclipse. Where does this "distributed footprint problem" come from? Is it Java? No, Java is much more efficient than most people think. Unlike C++, Java managed to provide an environment where class libraries, tool kits and frameworks from different sources work well together. Why reinvent the wheel, when someone has already done the work for you? You can focus on the application you want to create instead of getting lost in infrastructure. The price you pay is that the components you use are usually not tailored for your use case, but can often be used for a wider range of applications. More general libraries add overhead in performance and footprint, but they can drastically reduce the development effort.

Could we rewrite Eclipse (or Workbench) with a better footprint? We probably could. In some cases we could use better overall design, better algorithms or data-structures. Preserving the functionality Eclipse has today, we could maybe get an overall factor 2 or 3 if we are lucky (or good). But then it would probably be an island solution. We would have more applications running in parallel, which then would add to the overall footprint.

What can you do to speedup your desktop applications today? In most cases adding memory is the solution. Don't let you computer touch the hard-disk. Just go to the next computer shop and buy 2GB of memory and plug it into your computer. At least this is what helped me.

Domain Driven Design: Another buzzword?

A few weeks ago I bought the book "Domain Driven Design" by Eric Evans. For many years I've been very sceptical about "Design Methodologies", because they seem complicated and not really practical for the domains I've been working on. So, I did not expect too many new insight when I started reading the book....

How wrong I was! Ok, lets start from the beginning... The basic idea of Domain Driven Design is to come up with a language to describe the problem domain. This is called an "ubiquitous language", because the language is not only used in conversations but also in the formal model. The formal model is represented and implemented in the programming language of the system (e.g. java). This is a very agile process, as you understand the domain better you will update the model. The model reflects the understanding of the domain. Your understanding of the domain evolves, by discussing with the domain experts using the ubiquitous language. Keep the model and the design documentation up to date with your understanding of the domain. Because the language we use to talk about the problem domain is the same language we use when we talk about the model, we can reason on the formal model and see if the conclusions make sense in the real domain. This might sound like the simple approach: every "thing" you talk about in the problem domain is an "object". But it goes far beyond that. The idea is to distill the essence of the domain into the core model. Read Chapter 1 of Erics book to get some more insight on what Domain Driven Design is.

For many years I thought that I'm happy to work in a domain, where we, the developers, are the domain experts: I've been working on IDEs for more than 12 years (SNiFF+, eclipse). Before that I've been working as a scientist (physicist) in the area of computational molecular biology. Here again, "we" were the domain experts. No messing with "computer illiterate" domain experts. But after reading Eric's great book, I came to the conclusion, that being your own domain expert might make the design much harder, because it's so easy to get lost in the implementation details and so hard to come up with a ubiquitous language that represents the domains perceived by the user.

When I look at eclipse, I see that many areas of great design at the level of implementation and overall architecture. There's a great plugin infrastructure and the APIs are well though out. However, I also see some shortcomings when it comes to the domain models of the problems eclipse really wants to solve. Simply put: not all eclipse users are eclipse plugin-developers and the domain of software engineering lacks clear models in some places.

I also started looking into what we have done over the years and I realize that we ignored many of the principles of Domain Driven Design. I can see many areas where we should start building better models, making implicit concepts explicit, talking more to our users, not assuming that we know how software development works.

For many years I have been saying, that the documentation team should be part of the design team, because they have to "explain" the concepts at the end. My assumption is: software that is hard to explain is hard to use. Therefore, I thought that the documentation team should come up with the terms and the language to describe the system. They know the language best. In some sense, I was mentally putting the documentation team into the role of the domain experts. I also thought that my "language" problems have to do with the fact that English is not my mother tongue.

Domain Driven Design is like a revelation to me! I realized already that language is important but I never thought of formalizing the language into a design.

Now I'll take a fresh look at our designs. Let's see how this new insight helps me in my daily work....