The Developer Insight Series, Part 3: The Process of Writing Code

   
By Janice J. Heiss, May 2009  

Over the years, I've heard developers talk about their favorite code, funniest code, most beautiful code, how to write code, how not to write code, the obstacles to writing good code, what they love and hate about writing code, and so on. In the process, I've encountered many insights worth sharing.

Parts One and Two of this series provided advice on how to write good code. In Part Three, developers reflect on the actual process of writing code, how it happens, what it feels like, and how they do it.

Contents
 
Adam Bien: It's Almost Mystical
Kohsuke Kawaguchi: I Let the Code Flow From My Fingers
Chet Haase: I Take the Prototype Approach
Arun Gupta: Designing is the First and Most Important Step
Kelly O'Hair: Start NetBeans, Create Tests, Create Templates,. Fill in Templates
Josh Marinacci: A Lot Like Sculpting or Painting
Masood Mortazavi: Requirements, Design, Implementation
Shannon Hickey: Throw Together Methods and Prototype It
Richard Gabriel: Train Developers Like Poets and Artists
Tor Norbye: First Bang out the Basic Skeleton, and Then Incrementally Fill in the Gaps
Romain Guy: Start by Writing a Prototype
Éamonn McManus: A State of Flow
Alan Williamson: A Lot of Whiteboarding and Box Drawing
See Also
Comments
 
Adam Bien: It's Almost Mystical
link
Adam Bien
 

Adam Bien is a Java Champion focused on the Java EE platform. A self-employed consultant, lecturer, software architect, and developer in the enterprise Java sector in Germany, he implements Java technology on a large scale. He is also the author of several books and articles on Java and J2EE technology, as well as distributed Java programming.

 
"It is almost mystical and hard to describe. If you are really motivated, you can develop whatever you want in the shortest period of time. The sky is the limit."
 
 
Adam Bien
Java Champion

It is almost mystical and hard to describe. If you are really motivated, you can develop whatever you want in the shortest period of time. The sky is the limit.

To write good code, you have to understand the domain and the actual problem first. But the best way to learn the domain is to write code. So the challenge is to balance between bottom-up and top-down approaches.

I try to analyze the problem, then write some code, verify the solution, and sometimes adjust the problem to code in talking with customers. So the natural way to write code is in short iterations and feedback cycles with a short waterfall phase.

Read the full interview with Adam Bien.

Kohsuke Kawaguchi: I Let the Code Flow From My Fingers
link
Kohsuke Kawaguchi
 

Kohsuke Kawaguchi is a staff engineer at Sun Microsystems who has been working on XML and XML schema languages since 2001, in particular RELAX NG, W3C XML Schema, JAXB, and JAXP. He also hosts many projects on java.net and has more recently focused on web services.

 
"Sometimes I stop and draw pictures mentally or on paper, and that helps me decide how to proceed."
 
 
Kohsuke Kawaguchi
Staff Engineer at Sun Microsystems

Mostly, I just start typing into the IDE and let the code flow from my fingers. Sometimes I stop and draw pictures mentally or on paper, and that helps me decide how to proceed.

When a problem is more complex, I outline a solution and start noting the pros and cons. Once I'm done writing, I look at those notes and start writing an outline of a revised solution. I repeat this process until I feel comfortable.

I found that plain old paper is best for doing this, and this worked great when I was a student because I did it in history class, English class, and so on, where I didn't have a computer in front of me.

Read the full interview with Kohsuke Kawaguchi.

Chet Haase: I Take the Prototype Approach
link
Chet Haase Self-Portrait
 

Chet Haase is a senior computer scientist on the Flex SDK team at Adobe, focusing on graphics issues and features. In a former life, at the time of the following interview, he worked for Sun Microsystems as a client architect in the desktop Java group. He is coauthor with Romain Guy of the book Filthy Rich Clients: Developing Animated and Graphical Effects for Desktop Java Applications . He is also the author of a humor book, When I am King .

 
"I am never confident of a particular approach until I've gotten the main elements working in some simple way first."
 
 
Chet Haase
Senior Computer Scientist, the Flex SDK Team, Adobe

This process differs from person to person. I've known people (especially people who write software development books) who write a complete design before starting to code. I've known people who start with the code and write it from start to finish.

I take the prototype approach. Maybe it's insecurity or a need for quick gratification, but I am never confident of a particular approach until I've gotten the main elements working in some simple way first. So I start out writing ugly hacky code that just gets the basics working.

Once I've convinced myself that the approach will work, I step back and do the design and start writing better code. I read an interesting approach to this in Steve McConnell's book Code Complete. The trick to prototyping is to throw away the initial code and start afresh, to avoid any leftovers from that initial ugly prototype code....

I live for the times when I see the initial results come up on the screen. One of the reasons I'm a graphics geek is that I find it so satisfying to see the pixels on the screen that result from the math and algorithms in my code. When you see the pixels, you know that something's working, and when you see the pixels in the wrong place or color, you know that something's not working.

There's a cheap thrill from seeing the initial output from a prototype that tells me, "It's going to work!" Of course, the prototype took a half-day, and the real solution might take another month, but the best part is just seeing that it'll work eventually.

Read the full interview with Chet Haase.

Arun Gupta: Designing Is the First and Most Important Step
link
Arun Gupta
 

Arun Gupta is a technology evangelist for web services and Web 2.0 apps at Sun. He was the spec lead for APIs in the Java platform, a committer in multiple open-source projects, a participant in standards bodies, and a contributor to Java EE and Java SE releases. He holds a B.S. in electronics and an M.S. in computer science, both from Delhi University, India.

 
"Testing, performance, and documentation often are add-ons."
 
 
Arun Gupta
Technology Evangelist for Web Services and Web 2.0 Apps, Sun Microsystems

I strongly believe that designing is the first and most important step in writing any piece of code. Depending upon the size of the project, I prepare an optional one-pager describing the top-level requirements of the project. That one-pager is then converted into class and sequence diagrams using either a UML (Unified Modeling Language) modeling tool or annotations in the Javadoc format. These UML diagrams are then shared with the bigger team for an extensive design review.

After getting a buy-in from the team, these diagrams are then translated into interfaces, either using the UML tool capabilities or by hand-coding them. Once all the interfaces are ready, I implement them one by one. Segregating the interfaces and the actual implementation keeps the code modular and pluggable.

Testing, performance, and documentation often are add-ons. I keep them as part of my development cycle and would like everyone else to do the same as well.

Read the full interview with Arun Gupta.

Kelly O'Hair: Start NetBeans, Create Tests, Create Templates, Fill in Templates
 
"Write more tests. Run tests. Debug code. Run tests."
 
 
Kelly O'Hair
Senior Staff Engineer, Sun Microsystems

Kelly O'Hair is a senior staff engineer at Sun Microsystems, where he has worked since 1993. He works in the Java Development Kit ( JDK) core serviceability area, with a current focus on improving the JDK builds.

Start NetBeans. Create tests. Create templates. Fill in templates. Run tests. Debug code. Run tests. Write more tests. Run tests. Debug code. Run tests. Write more tests. Run tests. Debug code. Run tests. Write more tests. Run tests. Debug code. Run tests. Write more tests. Take some time off. Then come back and automate the build and testing.

Read the full interview with Kelly O'Hair.

Josh Marinacci: A Lot Like Sculpting or Painting
Josh Marinacci
 

Josh Marinacci has spent the last 10 years writing Java technology-based user interfaces (UIs) for wireless, web, and desktop platforms. After tiring of web programming at a home improvement retail center, a wireless carrier, and a document-management company, he joined the Swing toolkit team at Sun to return to high-quality UIs. He has recently contributed to JavaFX.

 
"Iterative development is the key."
 
 
Joshua Marinacci
Swing Toolkit Team, Sun Microsystems

For me, writing code is a lot like sculpting or painting. I begin with a sketch of what I want to make. Sometimes this is a feature list and sometimes a real physical sketch with paper and pencil. After laying out my ideas, I build a first version using rapid-development tools like Matisse in the NetBeans IDE, often stubbing in features like persistence or talking to the network.

Once I have the basic concept down, I methodically implement features and fix bugs, constantly going over the interface looking for flaws. After a while, I show it to someone to get feedback and then dive back into the code.

Iterative development is the key. Even when I'm fixing bugs in Java SE 6, where I'm not creating new software, I will iteratively arrive at a bug fix by first reproducing the bug, then coming up with a quick fix, and finally refining the fix to address backward- or forward-compatibility concerns.

Read the full interview with Josh Marinacci.

Masood Mortazavi: Requirements, Design, Implementation
link
Masood Mortazavi
 
 
"When writing code, I used to imagine and dream about a 3-D development environment where I could literally wire and work with color-coded objects through large movements with my hands and a voice-activated system."
 
 
Masood Mortazavi
Software Engineering Manager, Sun Microsystems

Masood Mortazavi, a software engineering manager at Sun, started his work with the company on the Java EE development team and as an expert in continuous availability issues and telecom collaborations with the Java software group. In recent years, he's managed teams of engineers who contribute to open-source databases such as Apache Derby, PostgreSQL, and MySQL. He holds many degrees, including a Ph.D. in computational fluid dynamics from U.C. Davis.

From a formal standpoint, it's easy to describe: Requirements, design, implementation. From an informal standpoint, it's more subtle: interpretation, conception and imagination, creative meeting of constraints.

What tools or systems we use are secondary, and unfortunately in programming, they often get in the way, because they can be hard to work with. Creating and running your first "hello world" program in a new environment can be much harder than writing your largest piece of code in the same environment.

Creative inventions in how we program can bring huge benefits to writing good programs. When writing code, I used to imagine and dream about a 3-D development environment, where I could literally wire and work with color-coded objects through large movements with my hands and a voice-activated system.

Read the full interview with Masood Mortazavi: Part One and Part Two.

Shannon Hickey: Throw Together Methods and Prototype It
link
Shannon Hickey
 

Shannon Hickey worked for Sun Microsystems from 2000 to 2008, where he was the technical lead for the Swing team. He is currently a senior computer scientist at Adobe Systems. Hickey lives in Canada with his family and twin boys, who keep him very busy.

 
"I find the process quite exciting, and I'm always eager to get to the next piece of the puzzle!"
 
 
Shannon Hickey
Senior Computer Scientist, Adobe Systems

I tend to have a lot of energy, so if I'm really excited about solving a problem, the first thing I do is quickly throw together methods and prototype it until I get the right bits on the screen or the right behavior. That's my proof of concept. It might take an afternoon or a couple of hours.

But once I've proved that it works, I start thinking about how to properly design the API. Working on a toolkit team, or anywhere in Sun, we're writing code for others to use, so we have to think about creating the right API. Once we have committed to it, we can never pull it from the JDK. So we design it with developers in mind. There's a big difference between making it work really quickly for me and actually designing it flexibly. There's a lot to consider.

When I'm prototyping functionality for large projects, I often take a step-by-step approach, writing small pieces and then building on top of them. For example, let's say I want to write a drag-and-drop application that allows you to drag an icon around on the screen. I first put together the drag-and-drop support that moves bogus objects. Then I see if I can drag a specific icon such as a red rectangle around the screen. Next, I see if I can get an image to move around the screen. Then I write the code that generates the image.

I find the process quite exciting, and I'm always eager to get to the next piece of the puzzle!

Read the full interview with Shannon Hickey.

Richard Gabriel: Train Developers Like Poets and Artists
Richard Gabriel
 

Richard Gabriel was for several years a Distinguished Engineer at Sun Microsystems, where he researched the architecture, design, and implementation of very large systems, as well as development techniques for building them. He received his Ph.D. in computer science from Stanford University in 1981 and returned to school to get a master's in fine arts (MFA) degree in poetry in 1998 at Warren Wilson College. In 2007, he joined IBM Research as a Distinguished Engineer.

 
"Writing software should be treated as a creative activity."
 
 
Richard Gabriel
Distinguished Engineer, IBM Research

Writing software should be treated as a creative activity. Just think about it -- the software that's interesting to make is software that hasn't been made before. Most other engineering disciplines are about building things that have been built before. People say, "Well, how come we can't build software the way we build bridges?"

The answer is that we've been building bridges for thousands of years, and while we can make incremental improvements to bridges, the fact is that every bridge is like some other bridge that's been built. Someone says, "Oh, let's build a bridge across this river. The river is this wide, it's this deep, it's got to carry this load. It's for cars, pedestrians, or trains, so it will be kind of like this one or that one." They can know the category of bridge they're building, so they can zero in on the design pretty quickly. They don't have to reinvent the wheel.

But in software, even with something such as Java 2, Enterprise Edition or the Java implementation (or almost any of the APIs we define), we're rolling out -- if not the first -- at most the seventh or eighth version. We've only been building software for 50 years, and almost every time we're creating something new.

If you look at software developers and what they produce, if you look at their source code, the programs they make, and the designs that they end up creating, there is real variability. And some people are really good, and others are not so good.

So because you can program well or poorly, and because most of it is creative (in that we don't really know what we're doing when we start out), my view is that we should train developers the way we train creative people like poets and artists.

People may say, "Well, that sounds really nuts." But what do people do when they're being trained, for example, to get a master of fine arts in poetry? They study great works of poetry. Do we do that in our software engineering disciplines? No. You don't look at the source code for great pieces of software. Or look at the architecture of great pieces of software. You don't look at their design. You don't study the lives of great software designers. So you don't study the literature of the thing you're trying to build.

Second, MFA programs create a context in which you're creating while reflecting on it. For example, you write poetry while reading and critiquing other poetry, and while working with mentors who are looking at what you're doing, helping you think about what you're doing, and working with you on your revisions. Then you go into writers' workshops and continue the whole process, and write many, many poems under supervision in a critical context, and with mentorship. We don't do that with software.

Read the full interview with Richard Gabriel.

Tor Norbye: First Bang out the Basic Skeleton, and Then Incrementally Fill in the Gaps
Tor Norbye
 

Tor Norbye is a principal engineer at Sun Microsystems, where he has worked on development tools since 1996, most recently on the Ruby and JavaScript editors in the NetBeans IDE. He is also a co-host of the weekly Java Posse podcast. He has a master's degree in computer science from Stanford University.

 
"My approach is to code the functionality first, then test later, and then to turn the process around and write tests for cases I don't expect to pass yet."
 
 
Tor Norbye
Principal Engineer, Sun Microsystems

When I'm writing code, it's typically to implement some new feature, and my approach is to first bang out the basic skeleton, and then incrementally fill in the gaps, testing manually by executing the code as I go along. Once I have something basic working, I write some unit tests. When the basic tests are passing, I start worrying about corner cases. I approach these by thinking of every possible corner case and add unit tests for these. I then use these unit tests to hunt down bugs in the code.

Therefore, my approach is to code the functionality first, then test later, and then to turn the process around and write tests for cases I don't expect to pass yet, and use the tests to complete the code.

Another important piece of the coding experience is "listening" to music. In iTunes, I have a dedicated playlist named "Coding Music." Coding music helps me tune out distracting background noises and makes the whole experience more enjoyable. The trick is to find music that is not distracting -- which is why I put "listening" in quotes earlier.

Classical music works well, especially baroque music, but also fast dance-oriented music like Madonna's "Confessions on a Dance Floor." I don't always have the luxury of coding with music -- for example, during meetings or podcasts, I've got to look like I'm paying attention. Just kidding. I don't do that. OK, I do. But not always.

Writing new code from scratch is fun, but it's only 90 percent of the job. The other 90 percent is making the code presentable and correct. Debugging code is pretty different from cranking out new code. It typically involves spending a lot of time in the debugger, testing out hypotheses, sometimes writing some custom code to narrow down the problem space. However, I actually enjoy debugging as well.

I spent my first five years at Sun working on our C/C++ debugger, Sun WorkShop, where I got to not only learn all the tips and tricks of our debugger but also add support for new debugging features. I'll always have a soft spot for debuggers.

Read the full interview with Tor Norbye.

Romain Guy: Start by Writing a Prototype
link
Romain Guy
 

Java Champion Romain Guy is a user interface toolkit engineer on the Android Project at Google.

 
"Most of the time, I start by writing a prototype to validate my vision, which I then evolve into the actual code base by refactoring the code."
 
 
Romain Guy
User Interface Toolkit Engineer, Android Project, Google, and Java Champion

The way I write code has changed a lot during the last few years, with the advent of powerful new programming tools such as refactoring in mainstream IDEs. Most of the time, I start by writing a prototype to validate my vision, which I then evolve into the actual code base by refactoring the code. I use this approach at every level, from a few lines of code to a full application module.

The prototype approach is often taught assuming that the initial code will be abandoned, and you'll start out fresh, but I'm convinced that if you're rigorous, refactoring can yield excellent results. I also occasionally start with a sheet of paper or by discussing the project with someone to get a good idea of what the architecture should be....

The most fun part is at the end, when I can see the result of my work, especially when it matches exactly what I had in mind when I started. I love programming because it enables me to bring my vision to life. Considering how bad I am at art, I don't really have a choice if I want to be creative.

Read the full interview with Romain Guy.

Éamonn McManus: A State of Flow
Éamonn McManus
 

Éamonn McManus is the spec lead of the Java Management Extensions ( JMX) team at Sun Microsystems. As such, he heads the technical work on JSR 255 (JMX API 2.0) and JSR 262 (Web Services Connector for JMX Agents).

 
"You may also want to arrange to have a nearby mountain to stare at."
 
 
Éamonn McManus
Technical Lead, JMX Team, Sun Microsystems

At its best, writing code happens in a state of "flow" or immersion. It isn't really describable, but you know it when you're in it. It's not easy to attain, and most of the everyday work we do doesn't allow it.

To maximize your chances, you should ensure that you won't be interrupted when you're coding something big, and master your tools. Mastering your tools means being able to type fast without looking at the keyboard, knowing all the things your IDE can do to speed up your development, and knowing the key APIs by heart.

You may also want to arrange to have a nearby mountain to stare at.

Read the full interview with Éamonn McManus.

Alan Williamson: A Lot of Whiteboarding and Box Drawing
link
Alan Williamson
 
 
"I am someone who can visualize the solution very well, so when I see the class hierarchy set out, then I know it will work before I get anywhere near implementing the real meat of the code."
 
 
Alan Williamson
Java Champion

Alan Williamson, named the UK's first Java Champion in 2006, has spent more than 16 productive years as a developer. He was for several years editor in chief of Java Developer's Journal . On November 20, 2008, he conducted the first-ever immersive cloud computing boot camp, and was named editor of the new Cloud Computing Journal in January 2009.

I do a lot of whiteboarding and drawing of boxes! When it comes to writing code, I do a lot of boilerplating, laying out classes, method calls, etc., and don't worry about the details of the methods. So lots of return null; everywhere.

I am someone who can visualize the solution very well, so when I see the class hierarchy set out, then I know it will work before I get anywhere near implementing the real meat of the code.

Some people use other tools, such as UML, but I always found that it gets in the way.

Read the full interview with Alan Williamson.

See Also

Adam Bien Interview and Blog
Kohsuke Kawaguchi Interview and Blog
Chet Haase Interview and Blog
Arun Gupta Interview and Blog
Kelly O'Hair Interview and Blog
Josh Marinacci Interview and Blog
Masood Mortazavi Interview Part One and Part Two, and Blog
Shannon Hickey Interview
Richard Gabriel Interview and Blog
Tor Norbye Interview and Blog
Romain Guy Interview and Blog
Éamonn McManus Interview and Blog
Alan Williamson Interview and Blog
Developer Insight Series:
- Part One: Write Dumb Code -- Advice From Four Leading Java Developers
- Part Two: Code Talk

Rate This Article
 
 
Comments
Terms of Use