Seven habits of effective developers

Keep it clean, and keep it simple--that is the maxim software developers should adhere to.

According to Lee Chuk Munn, a staff engineer at Sun Microsystems Asia-Pacific, writing applications is like writing a book.

"I've learned various programming languages [but] it doesn't matter what language you write in, the story [you write] has to be good," Lee said, in a phone interview with ZDNet Asia. A 27-year veteran in software programming, Lee sits in Sun's software department where he guides the company's developers and network of independent software developers in using Java and Solaris.

"Programming is just an expression to a solution. A lot of it is about understanding and recognizing the problem and getting help. This [concept] is generic across all programming languages, it doesn't matter what you use--whether it's C+ or Java. The approach is still the same," he said.

"What irks me is developers today are churning out applications without any regard or love for it. That's my number one pet peeve. So, it's like they're doing it for the money which is good, if you're a project lead, but you need to put in some concern and care into what you're building and not just in shipping [the application]," he noted.

Lee listed seven habits that he said all software developers should possess to be effective in their job:

1. Understand the problem
Before you can deal with the problem, you need to first understand the problem you are trying to solve.

"From my observations, I find that developers aren't keeping to the point," Lee said. "When you write a program, you're trying to express the solution to a problem [but] sometimes, people approach a problem without even first thinking about it. So there may be times when there may already be a solution to a similar problem that can be adopted for the one you're trying to resolve."

For instance, Lee said, there are different algorithms engineers can use to write a sorting program.

To select the right one to use, developers need to first understand the size of the data--that the sorting program will be administered on--in order to decide which is the right algorithm to use. "Choosing the wrong one would put your application in jeopardy in future," he said.

Lee also highlighted the need to do the necessary research before starting development work, and to think about how people will go about using the application, so elements such as user-interface and design should not be neglected.

2. Use appropriate tools
Study various programming concepts and data structures, and start building a reservoir of software design patterns, Lee said.

While reference books are a good source of information, he cautioned that technology evolves too quickly to rely solely on static text-based recommendations.

"Have a general idea of what is available," he said, adding that developers can then use this as a foundation on which to build more complex applications.

He also urged software engineers to become well-versed in a variety of tools, and develop their own if there is nothing appropriate for the problem they are trying to solve.

Quoting American psychologist Abraham Maslow, Lee read: "If the only tool you have is a hammer, you will see every problem as a nail."

This Maslow concept has become so popular among software developers that it has been dubbed the "Golden Hammer" rule, which cautions engineers with limited knowledge or training of solutions that they run the risk of using only tools they are familiar with, but that may not be the most appropriate, when they develop a new program.

3. Strive for simplicity
Programmers should develop applications that are:

• Easy to understand;
• Easy to explain;
• Easy to maintain; and
• Easy to document.

Lee noted that simplicity is not only associated with purity or clarity, it also reflects the engineer's understanding of the problem. "Anybody can come up with a convoluted solution," he said.

Noting that debugging is twice as difficult as writing a program, Lee said software developers will have an easier time patching bugs if their applications are clear and uncomplicated.

4. Keep your code clear
Only incorporate code that you understand, and make sure others understand it, too.

Lee explained that software developers are like novelists, each has his own writing style. "Whatever style you adopt [doesn't matter], just make sure you write clearly," he said. "When you write codes, you need to keep them clear. Don't squash them, just like how you would apply text spacing when you write a novel."

Think also about how you organize and label your codes.

Lee said: "Put yourself as an author, how would you write something that others can easily understand and follow your thoughts? That's how a programmer should code as well."

While there are no standard code layouts or models software developers can adopt, there are recommended coding practices, he said.

Programmers working on a Java platform, for example, can visit Web sites that recommend certain methods of naming variables, he added. "So there are conventions which most Java developers would already know," Lee said.

5. Learn to debug
Identify bugs early in the development process, and deploy automated testing tools such as jUnit.

Tests will help ensure the program performs the task you developed it to do.

"A reasonable-size commercial application is never bug-free, especially operating systems or big applications," Lee said. "So developers try to do tests to remove fatal bugs that can render an application unusable or bring the whole site down."

He reiterated the importance of maintaining "clean" codes, noting that developers should always know what they are adding to their codes as they could easily inherit bugs from external sources.

"Sometimes, there are bugs in your codes, or in other [software] libraries that you may have bought or downloaded that you cannot control," Lee said, underscoring the need for developers to "test early, test often".

Software engineers can reduce the time to debug by isolating the faulty code, and fixing and retesting this particular section before piecing it back to the main program.

"For example, when you click on menu item 1 and 2 in the program before a bug appears, you'll have to keep going through levels 1 and 2 every time you test and debug the program," Lee explained. "So, instead of doing that, pull out this piece of code, test it and debug as a standalone. Once you're certain it's fixed, then incorporate it back into the [main] code."

6. Leverage what is available
Developers should also look for solutions or algorithms that are already publicly available, such as those highlighted in developer forums and mailing lists.

Asked if this would increase the risk of a security breach, since the program will be based on codes that the public can easily access, Lee replied that this was not necessarily so.

"For example, the Public Key Infrastructure (PKI) is pretty well-known and the mathematics [behind the model] is also well-known. But if you want to crack it, it's difficult because the key generation [code] is still kept private," he explained. "So, you can use public data but safeguard the codes that are critical to secure your application."

7. Continue to learn
Finally, like any other profession, software developers must always continue to learn, pick up new skills and improve.

Engineers can also learn from conducting a post-mortem or an evaluation after a project has been completed, Lee added. "We need to learn from our good and bad [projects], and try and be better the next time, and the next time after that," he said.

Can developers then balance the commercial need to push out applications as quickly as possible, with the need to write codes that are clean?

Lee believes they can. "A lot of people say if they don't have quantity time, at least they have quality. That's not true... You can't have quality time if you don't put in quantity time," he said. "There's commercialization [in software development] but there's also 'art' and 'good' codes. And you can achieve both."