Most developers just focus on getting the initial code done, ignoring the important questions that ultimately affect the total cost of development. This article will address how to handle these issues in a way that will benefit the total cost of development.

Beyond Just HelloWorld
In enterprise development, the ability to program the design doc is taken for granted. Managers and senior developers expect you to step up to other problems that focus on the entire life cycle as well as enabling teamwork. Beyond just getting the design spec for the initial beta, you should ask yourself these questions: How do I test, how do I document in case I become unavailable, and how do I write flexible code?

At the root of these questions is a focus on the entire project as opposed to just the immediate task. Understanding how your task fits into the larger context of the solution and then focusing on quality within that context actually helps you to construct better code. This in turn will improve the end customer's experience - which is the ultimate justification for the project. For each question, analyze impostor solutions (easy alternatives that do not cut it), why people still do not follow it, practical implementation steps, what the correct solution will cost, and benefits of the correct solution.

How Do I Test?
You are the average developer who just tested your component by manually running through each feature to confirm that it was done. Showing the manager just the key features (managers lack time to inspect every detail), you moved on to the next important task. The problem is, how do you know it is done, and how will you ensure that it remains done despite related code changing? Furthermore, you need to be able to reproduce that test to prove that you are still done. The industry best practice is to automate unit tests, and then apply those tests to a nightly build from source control. Because you will need to build testing artifacts anyway for your own tests, you might as well save those artifacts in an organized and reusable manner.

Impostor Solutions

• Lengthy unit test forms that need to be filled out, as opposed to low-maintenance code artifacts that test the inner details from the developer's perspective
• Developers that do not run their own unit tests
• Unit tests that do not handle regression testing

Practical Implementation Steps
Ask yourself "What unit tests will confirm that this works?" Most likely, by feeding the component predetermined inputs and comparing its output to expected values, you can confirm that it works. Figure 1 offers several examples of these inputs and outputs. Try choosing tests whose base data or expected results do not need to be compiled.

Ensuring that your class libraries work (which are easy to test) relieves part of the burden from Presentation layer tests (which have GUIs and are much harder to test). Some automation tools are NUnit (http://nunit.org) for class libraries and WinRunner (www.mercuryinteractive.com) or Silk Test (www.segue.com) for presentation GUIs.

What It Will Cost

• Learning several new tools, such as NUnit or a GUI test tool
• Possible license fees depending on the tool
• Initial extra coding to write the driver and stub
• Initial extra coding to update the test if a requirement changes

Benefits
Besides saving time on regressions, automated testing makes you more confident because you can show your manager, other developers, and the client that your component works. This also helps your relationship with managers because all managers appreciate the quality assurance that automated unit tests bring.

How Do I Document If I Become Unavailable?
Anyone who has ever had to fix someone else's obscure component appreciates proper documentation. But how will that documentation get there? Useful documentation doesn't just magically emerge. Because design documentation is often viewed as an artifact required for beginning the coding process versus a means of capturing knowledge, it is rarely updated once coding begins. Although almost all projects have some documentation, that documentation is often incomplete or ambiguous. You want the documentation for your code to be different.

Impostor solutions

• Documentation based on page quotas rather than useful knowledge
• Attitudes that assume that documentation will never change
• Methods that neglect internal documentation, assuming that all documentation must be formal

Practical Implementation Steps
Often, a developer has just crawled back from a two-hour interrogation with a subject matter expert, clutching hard-won requirements scrawled on miscellaneous sheets of paper. Exhausted from the meeting, he never puts that documentation into an electronic format (which is more permanent, sharable, and updateable). There are several quick and practical ways to catch that precious information, rather than let it slip and disappear like water in the desert.

Focus on useful documentation that actually helps, not just copy-and-paste redundant information for a "one page of documentation for every 1000 dollars" quota. Focus on documenting the actual information, not on formatting, merging to an unnatural client format, or pretty wording. You can always do that later if time permits.

Authoritatively keep documentation up to date. If you absolutely lack time to update a living or insignificant doc, at least make a note that the changed section is no longer accurate or relevant. Incorrect (and therefore misleading) documentation is worse than no documentation at all.

Instead of forcing all information into paragraphs, store it in a way that meaningfully represents that information, such as an outline, picture, or table (as shown in Figure 2). Good formats are quick because they contain only the needed content, you do not waste time on pretty wording, they are structured in a way that is easy to search, and they are more flexible than paragraphs that are sculpted word-for-word.

Take advantage of the documentation tools that are either free or likely already installed on your computer. Visual Studio.NET supports comment tags in code (such as /// in C#). You can get this same functionality for VB.NET via add-ins (such as VBCommentor at www.gotdotnet.com). You can then use a tool such as NDOC (http://ndoc.sourceforge.net) to compile your inline comments into MSDN-like help. Visio can create diagrams and charts, and Microsoft Word has great table, outline, and auto-indexing features.

What It Will Cost
The cost of documentation often comes down to the extra time to convert that diagram on a napkin to electronic format. As you become more proficient with documentation tools, this becomes almost second nature.

Benefits
Meaningful documentation spares other developers from reverse engineering your code, a practice that could be 10 times longer and more error-prone. The act of documenting also forces you to know what you are actually building, which in turn makes your development much quicker. It also sets clear expectations to the business users for what you are building.

How Will My Component Handle Requirement Changes?
You should always be aware of code flexibility for two reasons: (1) You know that you will be asked to make changes in your code. Why not think one step ahead and prepare for it? (2) Someone else might have to make changes to your code. By making easy-to-change code, they're more likely to be able to make the change themselves as opposed to disturbing you.

Impostor Solutions

• Making an unnecessarily complicated change process
• Copying the same code to multiple places ("It will be easy to change...it's all the same code.")

Practical Implementation Steps
The secret to flexibility is minimizing what needs to be updated to account for the new requirement, and making those things easy to change. The former is done through code reuse with OOP; the latter can be assisted by storing data in uncompiled sources.

Most important, know the language. All OOP languages (certainly VB.Net and C#) are designed for code reuse. If you find yourself copying and pasting the same code, perhaps there's a language feature you don't understand? Constants handle primitive types, enumerations handle enumerated lists, inheritance handles shared functionality among objects, interfaces handle similar objects with the same external methods signatures, and you can always abstract duplicate code to a single method. Be aware of what you code. If you ever find yourself copying and pasting code multiple times, ask yourself "Why?" Could you make it reusable with OOP features?

If ever you find yourself hard-coding data (such as literal string or integer values), ask yourself "How painful will it be if this is in production and management wants to change something?" It is far easier to change non-compiled sources, such as xml files, configuration files, or resource files. For example, always store any configuration values in the .config file.

What It Will Cost

• Mental energy to always be aware if the component should be abstracted.
• Overcoming the temptation to quickly hard-code data as opposed to storing it in external files.

Benefits
Making code flexible will minimize the time required to make a new change for both you and future developers who maintain your code. It will also make your code easier to read. For example, if you have a dozen user controls that implement an interface, you can instantly deduce the common functionality. This is much quicker than if no interface is used and you need to inspect each method of each user control.

Conclusion
There will always be one more thing to learn, but these questions transcend merely adding more knowledge to your skill set; they fundamentally drive how to develop every component you touch. Good practices such as these are commonly avoided because they take a little effort. However, we as developers cannot afford to prematurely start coding without answering these questions. If you want to create fully working components in an enterprise project, then you will need answers for these questions. Knowing how to test, document, and potentially change your code may take time up front, but it will certainly decrease the total cost of development, which is the thing that really matters.

• Figure 1
• Figure 2
• Table 1
• Table 2
• Table 3