Ron Hitchens's Blog: Programming Archives

I was lucky enough to spend all of last week at Software Development Expo West (SD West) in Santa Clara, California. I usually don't have the luxury of devoting so much time to a "non-essential" activity, but the stars just happened to align fortuitously. My wife is expecting our second child soon and I'd scheduled myself to be voluntarily unemployed at this time anyway.

I can't remember when I've learned more or had a better time at a technical conference. It's not only because I'm more-or-less at leisure (and therefore don't have deferred work nagging at my subconscious) but also because of the people. As with so many things in life, it's the people that really matter.

I wrote a book for O'Reilly and have done a little speaking at various groups and conferences as time and opportunity have permitted. Doing so has allowed me to rub elbows with many fascinating and well-known folks that I'd never otherwise expect to meet. A bunch of them were at SD West.

Lords of the Ring

I spent so much time talking with so many people at this conference that I often found myself standing in rings -- slowly expanding rings -- talking to all sorts of people about all sorts of things. Most of them were wearing Speaker badges.

If you've ever attended a conference and spotted a well-known author (or several) standing around on the show floor talking with colleagues but were intimidated to approach, don't be. Most speakers when attending a conference are more than happy to talk with you about their field of expertise -- that's why they're there. Join the ring. Step right up. Introduce yourself. Odds are they're talking about email spam or something equally mundane and will be happy for a change of subject.

Good technical conferences (and SD Expo conferences are among the best) are extremely valuable resources. They bring together a critical mass of big thinkers and important information that you just can't find in any other venue. Exploit that resource. Jump in and interact with the like-minded people around you. Participate.

Everything I Know Is Wrong

So, what did I learn at this great conference that I'm blathering on about? Let's begin at the end.

The last session I attended on Friday afternoon was by Allen Holub, with the provocative title "Everything You Know Is Wrong: Why Extends and Get/Set Methods Are Evil". This talk was based on a series of JavaWorld articles written by Mr. Holub (here and here, also look here). There are some deep insights here into the nature of Object Oriented vs procedural programming and how established practices are not always best practices.

At the end of this talk I knew I'd made these same mistakes and knew that I should have known better. I learned that I should constantly examine my assumptions, especially those I'm most comfortable with.

Rewind now to Day One. Most of the day I spent in a tutorial on Java Data Objects (JDO). JDO is a favorite topic of mine. I've used it in commercial projects and given presentations on it here and in Europe. I believe JDO is a great, under-appreciated technology that has yet to reach its full potential.

The tutorial on Monday was led by Kieron McCammon, CTO of Versant and a member of the JDO Expert Group. Even though I already know JDO very well, I still learned new things from Kieron. Later in the week, Craig Russell (Spec Lead for JDO) gave a presentation on the upcoming features planned for JDO 2.0. The forthcoming enhancements promise to make JDO a compelling solution for even the most demanding enterprise apps.

But the highlight of Monday was the lunchtime keynote by Steve McConnell, whose upcoming book Code Complete, 2nd Edition is highly anticipated. The first edition was published about a decade ago and the keynote was about how the software industry has evolved in that time. What I learned was that many of the principles underlying the Agile movement are not new and have manifested in diverse ways throughout the industry.

I also learned this week that Daniel Steinberg can never make it for lunch.

Jam-Packed Craniums

I won't bore you all with a complete rundown of my conference schedule for the week. But I do want to note a few don't-miss speakers that you should never pass up a chance to see.

Robert C. (Uncle Bob) Martin led a fascinating free-form discussion on Friday. It pretty much followed the subject matter of his amazing book, Agile Software Development: PPP, but ranged from speculation about parallel Hubble Bubble universes to the importance of 3x5 index cards. Bob Martin is one of the smartest (and apparently, nicest) people in this or any other Hubble Bubble. Whenever you have the opportunity, listen and learn.

I attended a very informative session by Mary Poppendieck on Wednesday about software productivity and lessons learned in recent years. Mary contends that the software industry is hurting right now primarily because of declines in productivity that have snuck up on us over the last few years, not so much because of recession or even offshoring. It's about process and processes in the software industry are often lacking when compared to more mature industries.

Jason Hunter gave a well attended talk on XQuery, a new W3C standard that's nearing completion. XQuery provides a standardized way of referring to and manipulating "jagged data" -- basically anything that can be represented as XML. XQuery is exciting because it could greatly simplify the task of working with the mountains of structured data that don't fit neatly into relational databases. XQuery is something to pay attention to (Jason too, for that matter). From Jason I also learned of a good burrito place in Sunnyvale.

The most entertaining event of the week was the evening keynote by pbs.org columnist Robert X. Cringely. One of the first things he said was "I used to be a developer -- now I'm developed". Funny guy. Smart guy. I can't remember much else of what he said. I was laughing too hard. I learned that back in the day, Apple must have been a hell of a place.

What Did You Learn Today?

So why does my rambling about yet another tech conference matter? I think it matters, at least to me, because I was reminded this week that it's important to always keep learning. And to keep re-learning that you need to keep learning. It's very easy to settle into a comfort zone and engage the cruise control.

The software industry in general and the Java platform in particular are undergoing seismic shifts. To survive you need to stay current and learn to see the big picture. You need different perspectives, new ideas and the courage to take on new challenges in a world where the old rules may cease to apply, conventional wisdom may become foolish and Moore's Law can kick your ass.

Life Renews

A new life will be joining my family very soon. I look forward to teaching her. But more importantly I can't wait to learn something new from her each day.

What did you learn today? Who will you teach tomorrow?

The End of the Beginning?

Posted by ronhitchens on December 30, 2003 at 02:13 AM | Permalink | Comments (9)

I love Java. I love writing Java code. I've even written a Java book. I've used zillions of programming languages and Java is the one I like the best. But there's a question that's been nagging at me lately: Does Java, or any programming language, really matter any more?

Having been in the computer business for a very long time - the first computer I ever worked with used punched cards and was as big as my first apartment - I've seen a lot of changes in the nature and public perception of computing. And I can't shake this feeling that we're in the midst of a profound, evolutionary change.

In his now famous article IT Doesn't Matter, Nicholas G. Carr makes the argument that the IT industry is maturing and has become effectively irrelevant to a company's competitive strategy. In and of itself, Information Technology no longer has any intrinsic competitive advantage. It's simply one of the essential ingredients needed to run a modern corporation - like electricity, telephones and foosball tables.

But my nagging feeling is not so much about business trends as it is about similar evolutionary forces acting on the technology of software itself. Carr refers to earlier technologies that have transformed industry (steam engine, railroad, telephone, etc). Throughout their lifecycles, each has initially transformed - or disrupted - their environment and then themselves been transformed because of the changes they brought about.

I believe software development is entering such a mid-life, transformative stage - it's changing because of the changes it's caused in business and society.

Computers are no longer exotic, science-fictional wonders, they're a part of our everyday lives. And, as the off-shoring trend of recent years has made excruciatingly clear, programming is no longer a rarefied skill exclusive to a gifted few. To a large extent it's become a routine trade that almost anyone - anywhere - can perform. A commodity.

But the shifting economics of earning a living as a programmer is not what I'm talking about either. That's a political and sociological discussion. The thing that's nagging at me has to do with the programming itself. The way we as humans communicate what we want a computer (or a system of computers) to do.

Software has historically been inextricably linked to computer hardware design. Assembler languages gave us a one-to-one translation of mnemonic symbols to the numeric codes that a CPU understands. Higher level languages brought a more semantically rich set of symbols, and a more complex compiler to do the translation, but we're still essentially expressing ourselves in terms a CPU can understand.

Object technology helps us conceptualize things a little better. We don't feel so constrained to the lock-step, linear instruction execution model. But when you look inside an object method, it's still made up of those fine-grained marching orders for a CPU. We still seem to be tied to the paradigm of writing text that's translated to the CPU's native language.

I've been wondering lately if this notion, abstracted though it may be, of people writing text that's then translated into opcodes isn't something we've outgrown. It's the 21st Century but the way we as programmers communicate instructions to computers hasn't changed fundamentally since Grace Hopper started doing it nearly 60 years ago.

I saw a demo at SD West 2003 of the work Intentional Software is doing and have read a little about the Ace and Jackpot projects at Sun, all of which are exploring alternate ways of representing code. But I've actually been intrigued by this concept since I decided to switch to IntelliJ/IDEA as my Java development environment.

IntelliJ was the first IDE I used that was designed around the concept of language understanding rather than text editing (it may not have been the first, it doesn't matter, it was the first one I encountered). IntelliJ is such a great tool to use because it understands the Java language. It instantly checks code as you type it both syntactically (is it well-formed) and semantically (does this make sense in the context in which you're using it). It's the latter that's really valuable - manipulating text is not what I care about, it's getting the code right that matters.

Once I got up to speed with IntelliJ, I noticed a subtle but profound shift in my thought process. I began to think of coding less as a text editing activity and more as an object crafting activity. Because the tool understood the language I could trust it to do the mundane editing tasks while I concentrated on the higher-level meaning of the code. This has far-reaching implications.

Rather than thinking of the code as lines of text, I now conceptualize it as chunks of functionality that can be split, combined or reshaped as needed. The chore of making changes to the text files is handled by the tool. I'm able to devote my concentration to the more important aspects of programming: responsibilities, relationships, cohesion, coupling, patterns, and all the other stuff that makes for well engineered software. And when I see that something needs to be changed I don't hesitate because the tool can make the change easily - even if that change may affect a hundred source files. This makes for better code and it makes me a better coder.

Tools like this use a sophisticated internal model to represent the code. Where there's a model, there's usually a view of that model. And if there's one view, why can't there be others? When a tool can present your code to you as UML diagrams, color selectors, tables, live GUI widgets or whatever, the textual view we're all so familiar with starts to feel rather constraining.

So this begs the question: If tools can liberate us from mundane text editing and we code so much better when interacting with a more wholistic model, why do we bother to keep the text file representations at all? In today's world, it certainly seems as though building programs by manually munging text files is one of the least efficient - and most expensive - ways to go about it.

I don't know what the next great innovation in programming will be. It may be here already for all I know. But I do know that the labor-intensive, text-based programming method we've been using for the last half century will wane - it's simply not going to be economically viable much longer.

A friend of mine once pointed out that the majority of business programming is done not in Java, C/C++, Cobol or even Visual Basic, but in Microsoft Excel. I wouldn't consider a spreadsheet a programming language, but it certainly is an effective way for humans to communicate to a computer what they want done.

This, I think, is where the future lies. Finding the most appropriate way to communicate for any given problem domain. The era of humans translating their thoughts into sequential steps for the CPU to execute is ending. Just as high level languages supplanted assembler because they were more expressive and hid more of the details of the execution environment, I believe the next phase will be to move beyond the textual representation of programming logic for most applications.

Of course, conventional programming languages are not going away overnight. I suppose what I'm really talking about here is a new sedimentary layer being laid down atop what's come before. The future is alway built on the foundation of the past. The programming languages of today will beget the next generation of programming tools.

I believe we've reached the end of the beginning of the computer revolution. But we're nowhere near the end. Just as printing technology evolved from letterpress to linotype to offset to laser printer, the nature of programming must also evolve. It's going to be interesting to see which mutations survive in this brave new Darwinian world. In any case, I'll be sad when I finally have to say goodbye to my old friend, Java.

Powered by
Movable Type 3.01D

java.net RSS Feeds