Google architect offers tips at ServerSide Java Symposium |
 |
By Rich Seeley, News Writer
27 Mar 2006 | SearchWebServices.com |
|
|
Las Vegas - It is an article of faith that every software development team only hires the best and the brightest programmers, said Gregor Hohpe, speaking to an audience of cutting edge Java gurus at The ServerSide Java Symposium in Las Vegas this past weekend.
|
|
|
|
|
Maybe the janitor comes in during the night and messes up our code?
Gregor Hohpe
Software Architect, Google, Inc.
|
|
|
|
|
|
|
|
|
|
"Which company would say we hire the dumbest engineers?" asked Hohpe, who is software architect at Google, Inc. His assumption is that bad programmers must be working in the limbo of the computer science universe.
But if all application development projects are staffed by first round draft choices, Hohpe wondered aloud how he keeps finding code that is a complete mess. He shakes his head when he finds comments in code that say: "this is wrong" or "performs arcane checks." How can this code and these comments be coming from the best and brightest?"Where did all the beautiful code go?" he asked, repeating the theme of his keynote.
In a facetious take on software developer paranoia, he suggested: "Maybe the janitor comes in during the night and messes up our code?"
As Hohpe sees it, code gets messed up for far more mundane and preventable reasons. Principal among them is that sloppy code begets sloppier code. His theory is that if the initial developer of an application doesn't take care to make his code clear and logical to any programmer that reads it, Pandora's box pops open.
The sequence of events Hohpe outlined begins with the developer writing code that is serviceable for the application – it runs okay – but the code itself is idiosyncratic and hard for another programmer to understand. The along comes a programmer doing maintenance a year after the application goes live. The code appears to be a convoluted mishmash.
So perhaps the second string maintenance programmer working on a revision, says to himself, "I'll just stick my code in here. How much worse can it get?"
After a few revision cycles like that an application that is getting a little long in the tooth may feature code originally developed by the best and the brightest, yet it's going from bad to worse.
He offered his audience at The ServerSide event tips for making sure this doesn't happen to their beautiful code.
"Write code that people aren't compelled to mess up," he said. "Make code so the next person sees you put thought into an elegant solution."
As an architect, he preached the value of modeling the application first. It doesn't even require sophisticated modeling tools, he said, suggesting that even a model drawn on a paper napkin can be a good start.
Reiterating his rule that programs should be written for people not machines, Hohpe said, "Model the people interactions." He said this is especially important when working on the user interface. He suggested showing the application to non-programmers, to see if the programmers' idea of how the application should work, makes sense to a potential end user.
He warned that the steps in so-called business logic are not always as clear cut as programmers might imagine.
"If business logic was really that logical, it wouldn't be that hard," he said. That is why it is important to find out how end users will actually interact with the application.
He urged the Java programmers in his audience to take advantage of the expressiveness in Java to write code designed for people and that other programmers will see as an elegant solution.
"Write code for people not machines," was Hohpe's mantra throughout his keynote. He suggested that if programmers were only writing for machines, they wouldn't need Java, they could revert to working in Assembler.
|
|
|
|
