Expressing strikingly similar opinions on the virtues of "dumb code," four Java developers interviewed by Janice J. Heiss in her Developer Insight Series, Part 1 discuss the importance of not striving for elegance but simplicity instead.

Sun Microsystems technology evangelist Brian Goetz says, "Often, the way to write fast code in Java applications is to write dumb code -- code that is straightforward, clean, and follows the most obvious object-oriented principles." This has as much to do with compiler optimization as anything else, according to Goetz. Write "clean, dumb code," he advises, rather than "really clever code," especially in Java.

If simple straightforward code leaves something to be desired, he continues, then, and only then, optimize but with clearly defined performance metrics in mind. And be prepared to do plenty of testing under realistic conditions rather than simply assuming things will work as you intended. Do the testing, even though it's more difficult in Java than in C. "Java applications don't work like C," he asserts.

Java Champion Heinz Kabutz sees "good code" resulting from "...using good object-oriented design patterns ... Teams that employ good design patterns find it much easier to tune their code, which will be less brittle and require less copying and pasting," he continues. "Good design allows you to more easily change code and detect bottlenecks," he adds, providing an example to bolster Goetz's point.

Similarly, Java Champion Cay Horstmann says he, too, agrees with Goetz, adding that developers should not optimize until they have done their profiling.

Horstmann diverges a bit from Kabutz's point of view, averring that, "I agree that patterns should be a part of everyone's education, but I've had too many junior programmers sprinkle patterns over their code in the hope of improving it. Patterns are not magic potions, and it takes quite a bit more experience than is commonly acknowledged to use them wisely."

Yet another Java Champion, Kirk Pepperdine, puts it quite simply: "Dumb code tends to be more readable and hence more understandable. If we can iron out the twists, then we have a better chance of avoiding the dumb mistakes that clever code may hide from us." Pepperdine also advises against what he terms "premature optimizations."

Pepperdine also enunciates two principles that he likes to see observed: 1) Don't Repeat Yourself (DRY); and 2) Delegate, don't assume responsibility.

Repeating code invites the creation of unintended consequences when changes in one part of the program are made that cause undesirable effects in another. Encapsulating and delegating calls, for example, helps developers steer clear of this problem, he asserts.

In the end, what Pepperdine likes to see is " ... loose coupling, simple code, following good design patterns, having good unit testing in place, automated builds, and so on ...."

In The Developer Insight Series, Part 2: Code Talk Heiss chats first with Google's chief architect, Joshua Bloch, himself a critic of premature optimization, advising instead that developers not assume that " ... the general warnings about premature optimization don't apply... because you just know which code is time-critical and how to make it fast. But no one can determine this without measuring before and after each attempted optimization."

Bloch also advises against developers overlooking perfectly good code from libraries and, instead, writing their own, conceding, however, that, with such a plethora of libraries, it is difficult to keep track of what's already been written.

Masood Mortazavi, a software engineering manager at Sun, keeps it simple: "The best code makes the least and only the absolutely necessary assumptions, if any." As he puts it, developers should avoid "... local variables, which only serve for internal bookkeeping. The more internal bookkeeping we do, the more verbose our program becomes, which means the code will begin demanding that we break it up into more classes and methods."

Jason Lanier, currently the interdisciplinary scholar-in-residence at the Center for Entrepreneurship & Technology, U.C. Berkeley, finds it odd that developers cannot scale their products as aircraft designers, for example, can scale theirs. "The problem with software is that we've never learned how to control the side effects of choices, which we call bugs," he contends. He also bemoans the complacency among contemporary developers that things will always be as they are now.

Victoria Livschitz, CEO of Grid Dynamics and former Sun principal technologist, shares Lanier's view that large scale programs beget numerous bugs. She urges "preventive" measures such as "typing that allows compile-time assignment safety checking, garbage collectors that automatically manage memory, and exception mechanisms that trap and propagate errors in traceable and recoverable matter do make programming safer." Livschitz also distinguishes between programming bugs and design bugs, seeing the possibility of minimizing these to a limited extent.

Livschitz also has some interesting comments on the connection between complexity and the Java language, noting that, "The power of intuitively understanding the meaning and relationship between things is the proverbial silver bullet, if there is one, in the war against complexity."

In future, Livschitz sees an evolution from object oriented programming to something based on a small number of primitive concepts, intuitively obvious to any mature human being, and tied to well-understood metaphors, such as objects, conditions, and processes.

Finally, Brian Harry, renowned Java bug fixer says, "Bug fixing is a great way to understand how the code works. Reading the code is fine, but working with it is better. Even if you don't find a solution, you'll learn and become a more powerful developer."

Among the tips he has to offer bug fixers are:

1. Work with the test attached to the bug report

2. Make sure you are really dealing with a bug.

3. Jot down your thoughts as you work on a bug and publish those with your patch.

4. Consider writing multiple solutions.

5. Find out with the patched code interacts with. [...read more...]

		fullsource
Print Email Current Profile Archive Blog Generate newsletter