- What Is a "Value Chain"?
- What Is the Programming Value Chain?
- Attributes of Programmers High Up the Value Chain
- Attributes of Programmers at the Bottom of the Value Chain
- Moving Programmers Up the Value Chain
- Should Developers Specialize?
- Conclusion
- References
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Attributes of Programmers High Up the Value Chain
The following attributes distinguish developers who operate from high up the value chain:
- Awareness of other parts of the value chain
- Ability to perceive distinct software concerns
- Interest in incorporating proven techniques
- Keenness to use the latest ideas
- Forward thinking (for instance, intelligent logging)
- Good coding practices
Be Aware of Others
If a given developer has a good appreciation for the needs of software testers, then it’s a fair bet that he or she will try to produce code that makes life easier for the quality assurance group. This improved code can have a pleasant side benefit for the programmer: reducing the number of issues raised by QA. For this reason, it’s always a good idea to encourage developers to move around the areas depicted in Figure 1.
Work Modularly
Good developers are acutely aware of the need to create and understand modular software structures. The trendy term for such structures is cross-cutting concerns. An example of such a concern is the implementations for logging and security. An erroneous change to a cross-cutting concern is just about guaranteed to upset all your colleagues! The problem with cross-cutting concerns is that they’re often visible in the finished software as monolithic features, while in the source code they’re spread across many code files.
Incorporate Proven Techniques
Good, ambitious programmers like to incorporate design patterns, such as the command pattern, into their work. This technique can substantially reduce the effort required to implement a given algorithm. The logic here is that if someone else has done most of the hard "thinking" work by creating a pattern, why bust a gut essentially duplicating the effort? A plethora of new patterns are at the disposal of all programmers.
Take Advantage of Open Source
The latest ideas in software development may stem from open source projects. The best programmers are hungry for such ideas and apply them when appropriate. While not new at all, skillful use of inheritance and polymorphism can enhance reuse as well as making code concise, elegant, and often easier to understand.
Write Behind, Think Ahead
Forward thinking is all about making life easier for the time when you forget how a given piece of code works. (Or when some other unfortunate individual has to assume ownership of your code.) While low-tech and often shunned by developers, concise and meaningful documentation is the preferred order of the day here. A well-phrased comment can help in understanding even the most difficult source code.
Practice Good Coding Principles
It’s axiomatic to say that good programmers follow good programming practices. It’s more helpful to say what those practices are! One simple example is the way in which good programmers write code that calls into external entities such as libraries or foreign language modules. Many modern Java applications use JDBC for database access, and it’s common to see direct calls to JDBC peppered all over a code base. A level of indirection is a better solution, with all calls to JDBC located in a special-purpose adapter class. Then, when database access is required, the programmer makes use of the adapter class. This example of the adapter design pattern is a clear example of good practice.
It’s a similar story for foreign language code called from Java. Rather than rewriting legacy C code in Java, it’s possible to call straight into the C language code. There are pros and cons for choosing to call the C code directly, but the key point is that direct calling can save a great deal of time and help to preserve legacy investments.
The best way to achieve external calls is to minimize the impact on your code. Let’s consider an example. Listing 1 shows Java code that calls into a library module written in another language.
Listing 1 Java code that allows calls into foreign language code.
class HelloWorld {
private native void print();
public static void main(String[] args) {
new HelloWorld().print();
}
static {
System.loadLibrary("HelloWorld");
}
}
Listing 1 uses the Java Native Interface (JNI) to load an external library written in C. This is a clean interface, and just a small change is required to the legacy code, as illustrated in Listing 2.
Listing 2 Foreign language C implementation code.
#include <jni.h>
#include <stdio.h>
#include "HelloWorld.h"
JNIEXPORT void JNICALL
Java_HelloWorld_print(JNIEnv *env, jobject obj)
{
printf("Hello World!\n");
return;
}
The mechanism in Listings 1 and 2 can provide massive savings in time where access is required to special-purpose legacy code.
For another example of a good practice, how about the Ant script in Listing 3?
Listing 3 A simple Ant build script.
<target name="compile" depends="init"
description="Compile all code">
<echo message="Compiling the client- and server-side source code...."/>
<javac
srcdir="${src}"
destdir="${temp}"
classpath="${dom_location}/${dom_jar}" />
</target>
Notice the echo message tag. When the script is run (for instance, by running the command ant), the message appears on the console window, as shown in Listing 4.
Listing 4 The echo message.
compile: [echo] Compiling the client- and server-side source code....
The description tag in Listing 3 is useful when you run the command because it’s listed as part of all the targets in the build script (see Listing 5).
Listing 5 Listing build file attributes.
ant -p Buildfile: build.xml This Ant build script builds all program components. Main targets: clean Clean up build folders compile Compile all code make_jars Make the JAR files Default target: compile
By running the command ant –p you can see all the targets implemented in the script file. This approach helps in finding your way around such script files and getting the most from your build tools. Such fine details make the difference between operating from high up as opposed to low down the value chain. All of the attributes of the best programmers combine to produce a substantial value add. But what about developers operating from low down the value chain?