Enterprise Integration Patterns
Gregor's Ramblings

A Chapter a Day...

FEB 1, 2010

Gregor HohpeHi, I am Gregor Hohpe, co-author of the book Enterprise Integration Patterns. I like to work on and write about asynchronous messaging systems, service-oriented architectures, and all sorts of enterprise computing and architecture topics. I am also an Enterprise Strategist at AWS.
ALL RAMBLINGS  Architecture (12)  Cloud (11)  Conversations (8)  Design (26)  Events (28)  Gregor (4)  Integration (20)  Messaging (12)  Modeling (5)  Patterns (8)  Visualization (3)  WebServices (5)  Writing (12) 

My blog posts related to IT strategy, enterprise architecture, digital transformation, and cloud have moved to a new home: ArchitectElevator.com.

...keeps the writer's block away. My New Year's resolution was to write more, so here my thoughts on how to actually make that happen. In a sense it's a plan for myself to be more productive, but hopefully the ideas also work for other folks. Ironically, my work on EIP II has been stalled for a good while, so you're getting advice on how to be a prolific writer from someone who has not written much in 2 years. Read on at your own risk.

Harness the Power of Procrastination

You can easily tell when I am “writing”: the house is 105% dust-free, no dirty dishes are to be found anywhere in the kitchen, and all laundry clean and neatly folded. Twice. That's the power of procrastination (it's certainly not the normal state). It's hard to avoid procrastination, but you can try to make it work for you. For example, if your goal is to write a whole book, you can easily procrastinate by writing blog entries or chapters for books. For example, that's how my chapters in EAI Expertenwissen and 97 Things every Architect Should Know, or this rambling came about. I still did not work on my book much, but at least I got some work published.

Write *Something* Every Day

The cliff of freshnessEven you feel like you are in no condition to write anything useful, write something. Or at least copy edit some text or draw a new diagram. One of the biggest dangers is for your mind to go stale, i.e. you forget the "story" or "spirit" of the book. Writing is a slow activity, so it's natural to have many open "threads" in your mind at one time. But you can't keep these threads idling forever. I call it the "cliff of freshness": if you don't write for a few days, no problem. After one week, I slowly start to forget some of the open threads. After 2 weeks, they are mostly gone and I end up having to re-read what I wrote and slowly reconstruct where I wanted to go. Keep your mind in the fresh zone by doing something related to your writing every day. When I wrote EIP my co-workers refused to eat lunch with me unless I promised not to talk about "the book" – because that was the only thing on my mind.

Use Your Best Hours – Mornings

I got this advice from Martin Fowler, who has the luxury of living on the East Coast in a company that has many projects further westwards. This allows him to write in the morning before his regular work day starts. As most developers, I tended to do most of my work late at night, but I recently followed Martin's approach. Not because I have a time zone advantage, but because many developers only get into the office at around 11am (to avoid the train rush). So I try to write from 8am to 11am 3 days a week, as long as I can fend off meetings with California, which tend to be in the mornings. Nothing feels better than showing up for the daily grind with 3 hours of fun work under your belt.

Reward Yourself

A good state of mind is important for writing. Some new gear can be very helpful to put yourself into a positive state of mind. I love my new laptop after I had been so frustrated with my company Thinkpad for a long time. Thinkpads are not actually bad machines, but the combination of an encrypted hard drive, overly zealous virus checking, too little drive capacity, and memory hungry Chrome meant that the machine swapped itself to death. It often took 30 seconds for a Chrome tab to refresh or even open. I ultimately realized that my time is more valuable than that, so I got myself a shiny new laptop, one of those funny looking Panasonic Let's Note. It's very Japanese including the ridiculously cute name, but it offers an outstanding combination of power (2.53GHz dual core), light weight (just over 1kg), battery life (I get 10h+), and sturdiness (supposedly survives 70 drop with no issue). Now that I spent all this money, I better use it to write!

Read More

Nobody writes in isolation. Part of writing is also to read more to get inspired, and see what other folks are working on. And when you are totally out of ideas on what to write, you can simply write about the great thing you read. I am considering getting the small Kindle to be able to read and review comfortably anywhere. Except PDF's don't show terribly well, largely because PDF is meant for page layout, not for reading on a 6" screen. But I hear you can easily convert to the Kindle format and solve this problem. Plus getting a Kindle also falls into the previous point of making an investment / commitment.

Capture Ideas Anytime Anywhere

Good ideas don't arrive on schedule. They also tend to disappear quickly, so it's useful to have something to jot down ideas with you any time. It can be as low tech as a tiny notebook or as high tech as an iPhone. Many good ideas come from talking to other folks, so maybe it should not be considered rude to take notes during beer chats. Maybe that's what the coasters are for? How about the proverbial idea in the shower? Don't get the fog free mirror.

Start from Different Angles

When you flip through EIP, you may notice that the amount of code increases towards the end of the book. That's mainly because we got so tired of writing that it seemed easier to code (see also "procrastination"). So try different tacks instead of just typing words. Make up a picture, sketch something out, code up a solution.


I am not talking about scribbling on the back side of your printer paper here, but about recycling ideas. I found that I have good ideas of how to explain things when I prepare a talk. But too often I don't actually write about them or, worse yet, I forget about them. So turning a talk into a short article or a blog post into a book chapter can be quite productive and keeps your mind fresh.

Announce Your Progress Publicly

I saw many tweets from Martin on his DSL book. Announcing your progress is a good way to make a commitment and share your success.


The notion of someone locking themselves up for 3 months in a dark chamber to write a book is in fact quite rare, at least for technical books. These days, a chamber with WiFi may do the trick, but the reality is that the majority of good technical books are the result of a community effort based on formal and informal reviewers. So don't be afraid to share your work. Nothing is a better motivator than receiving useful feedback.


Many authors state that the chances of success for a book co-authorship is lower than that of marriage. While that may be the case, having a co-author is great to get you over lows or busy periods. If you write by yourself, it is just too easy to drop things. If you have a co-author, you can balance between the two (or three) of you and make steady progress. I think one of the reasons we actually finished EIP was because we were a team of two.

No Silver Bullet Here Either

Let me conclude with my insight that writing books is infinitely more difficult than writing code. I can happy crank code 10 hours a day without breaking a sweat (even though I rarely do these days). On the other hand, 5 hours of intense writing wipes my brain out completely.

Will my advice work for me? Ask me in 6 months. My plan for this year is to speak at fewer events and dedicate more time to writing. Of course, meeting fellow authors and "intellectual drinking buddies" at events is still an important part of staying ahead of the curve and getting ideas and inspiration. So it's unlikely that I'll go into complete isolation. My talks RSS feed should keep you up-to-date.


Follow:       Subscribe  SUBSCRIBE TO FEED


Gregor is an Enterprise Strategist with Amazon Web Services (AWS). He is a frequent speaker on asynchronous messaging, IT strategy, and cloud. He (co-)authored several books on architecture and architects.