Plight of the introvert programmer

I have grumbled before about the trend away from private offices towards cubicles and open plan offices. At the same time, there are people who genuinely prefer these offices, which I considered inhumane. Then I read a book: "Quiet: the power of introverts in a world that can't stop talking", by Susan Cain. It helped clarify the differences between introverts and extroverts, the rise of the latter, and the implications all this has on workplace productivity.

Introvert, extrovert

Cain's definition of introversion and extroversion is pretty much what you would expect if you are familiar with Myers-Briggs. She emphasizes that "introvert" does not mean shy nor anti-social. Rather, an introvert tends to focus on the inner world of thought and feeling, enjoys solitude, dislike conflict and focus well. An extrovert would be the opposite, focusing on the exterior world and social interaction, are comfortable with conflict and enjoy multitasking. Another way to look at this is to say that introverts are more sensitive to outside stimulation, such as noise or people, and thrive at lower levels of such stimulation. Conversely, an extrovert needs a greater intensity of stimulation to feel "right". An introvert needs solitude to recharge after experiencing elevated levels of stimulation. An extrovert is the opposite: he recharges with social interaction.

The difference between introverts and extroverts -- keep in mind this is a continuum rather than a binary distinction -- in terms of optimal stimulation levels helps explain work environment preferences. An introvert works best in a relatively quiet, distraction-free environment, such as a private office. An extrovert is energized by the constant social interaction of pair programming and the bustling activity of an open plan office.

Programming at the speed of thought II: JRebel

In my last blog post, I lamented the slow turnaround and overall heaviness of enterprise Java development. I also said that I would be checking out JRebel, a tool designed to let you make code changes and push them out to a running application without restarting the application. My verdict? I loved it, convinced my boss to buy it, and am an enthusiastic user. But it is not flawless, so adopters should keep expectations realistic.

My blog will make you stupid

Apparently, my blog will make you stupid. It's no good fleeing to another blog, though: they all make you stupid. That is, if you agree with Nicholas Carr's book, "The Shallows: What the Internet is Doing to Our Brains". The thesis of the book is that our use of the Internet is changing our brains, affecting deep learning, long term memory and our ability to focus.

I first heard about this book at a No Fluff Just Stuff developer's conference, where more than one panelist at one session cited this book with respect. Clearly, I thought, this is not a book for Luddites if a bunch of technophiles are reading it. This book is not a reaction against modernity. In fact, I'd say that it is trying to preserve an aspect of human progress now threatened by the Internet. I'll get to that in a moment.

XDepend (now JArchitect): managing code complexity

At a NEJUG presentation I attended a while back, the presenter used a vivid metaphor of taming the "complexity dragon", meaning the tendency of a code base to become brittle and complex as it grows in size. This dragon can cripple even competent development teams: productivity plunges because each code change triggers bugs in other obscure parts of the program. That said, the presenter hastened to clarify that he meant European dragons, since apparently dragons aren't necessarily evil creatures in other cultures.

A major contributor to large code bases becoming brittle is the dependencies between pieces of code. If class A uses class B, then A depends on B and a change in B may cause A to malfunction. That's not too bad if there are only 2 classes, but becomes impossible to track manually as code bulks up. The difficulty is that complexity, as measured by the number of dependencies between units of code, does not merely increase linearly with the quantity of code. In fact, the function is quadratic and the curve is parabolic.

This is why architecture-minded folks try to impose certain code architectures: to tame -- though never quite slay -- the dreaded complexity dragon. When architectural layers are enforced, code in certain layers cannot directly use -- and depend on -- code in certain layers, and generally dependencies only go in one direction. These boundaries break up the n^2 function. Or they may try to eliminate cyclic dependencies: cycles couple code units together, preventing them from being tested or used in isolation. Or they may use various code metrics to discover potential trouble spots.

This may sound admirable, but for any code base big enough for such architectural enforcement to be worthwhile, I can't imagine doing this exploration by hand. I'd need a tool. Fortunately, there seems to be quite a number of tools out there. The folks responsible for XDepend (now called JArchitect) were kind enough to give me a copy to review. I don't pretend to be any kind of authority on this topic, nor even come close to mastering this tool. But I think this tool is cool enough for me to share a few of its features.

Dependency matrix