Best practices? Or bestest practices?

Transform your app-dev quality by involving the whole community in testing
As the saying goes, the more eyes you have on software, the shallower the bugs. That’...

Build your dev and test labs for less – a lot less – with virtualization
You don’t have the budget to equip developers and software test teams with all the har...

Software Common Hacks and Counterattacks: A Guide to Protecting Software Products against the Top 7 Piracy Threats
Software piracy continues to be a growing epidemic. This white paper examines prevalen...

By Larry O'Brien

August 15, 2008 — The very best practice in software development may well be to embrace the understanding that there is no single “best” way. Everyone does their best a little differently: reducing pages of hand-written notes to a few equations, the implementation of which is trivial; writing a program on the couch while a football game plays in the background; rolling out new features month after month; or participating in an enterprise-wide rollout that takes 18 months to plan and deliver. All of these might be one's "best" experience, but all of them are developed in very different ways. So, let's narrow things down a bit.

Corporate development is that of software built for commercial purposes, but not for direct resale. It may generate value directly, as in a Web storefront, or indirectly, as in supply chain coordination, but at its core it is in service to the company's bottom line. Corporate development embodies significant domain knowledge and business rules; this creates a characteristic combination of logic that's "so obvious, no one's ever stated it" and, likewise, it’s "not understood but has to be implemented to stay competitive."

There's typically a Web component to such software, but 100% compatibility with all the world's browsers and OSes is not usually a concern; a requirement to use IE or even a beta version of Silverlight may well be acceptable if it delivers high value.

Speed of development is the final sticking point for corporate development. All corporate development teams have a backlog. Even—maybe especially—in companies that don't consider themselves in the business of software development, time to develop and time to deploy are often the two factors that control the rate at which the company can seize new opportunities. So there is always a premium on high productivity in corporate development.

But in opposition to high productivity is risk: risk of major delay, risk of a show-stopping technical incompatibility, or risk of embracing a tool or technique that is reaching the end of its evolution. Such risks can have huge costs, and it’s very reasonable for project managers to make conservative decisions, especially when it comes to critical infrastructure components. (Prototypes, one-off conversion programs and administration automation are, in contrast, places where there is less risk in exploring newer technologies and techniques.)

Case(Microsoft)
In the corporate world, the two mainstream choices for development are Microsoft’s technology stack and a Java-centric technology stack. The LAMP (Linux-Apache-MySQL-PHP) stack is not uncommon, especially for storefronts or other customer-facing facilities. And even though dynamic languages such as Python and Ruby are unquestionably entering the mainstream of corporate development, they probably still remain a little bit on the risky side.

For most shops, the choice of platform was made years ago. Switching stacks carries with it a very significant risk, with a certainty of retraining and retooling costs, and a near-certainty of rewriting costs. This can be mitigated by the use of tools such as JNBridgePro from JNBridge, which allows Java code to run on top of Microsoft’s Common Language Runtime (CLR).

If you’re on the Microsoft platform and doing corporate development, it's essentially a given that you ought to be developing for the .NET Framework and CLR. The main languages for .NET programming in a corporate environment are C# and Visual Basic. Again, while there is a great deal of talk here and online about alternative languages that range from F# to Ruby to Erlang, choosing one of these off-brands for core development would still be considered a high-risk move.

Microsoft’s IronPython is “first among equals” of these emerging languages, and it’s a safe bet that lots of stuff to be shown at the upcoming Professional Developer’s Conference—scheduled for Oct. 27-30 in Los Angeles—will be driven by it. The combination of Python and Silverlight can be dazzling even before considering what will be unveiled at PDC, so even a conservative manager would do well to find some small project in which to explore these technologies.

The most difficult technology choice on the Microsoft platform today may well be which UI framework to use for browser-based applications. The conservative approach has a minimalist elegance, with ASP.NET pages that have a high degree of separation between cascading style sheets, content written with HTML and calls made to specific rendering functions. On the other hand, Microsoft's ASP.NET Model-view-controller framework, now in its third round of preview release, has come on like gangbusters. At this point, ASP.NET MVC seems to have passed every test regarding high productivity and has a nice design, a good programming model and a fairly high number of developers working in it.

When talking about a browser-hosted interface that needs to be dynamic, there's always a temptation to move away from the kludge-y mess of HTML and JavaScript known as AJAX and toward the use of a truly dynamic "black box" that runs inside the browser. Adobe Flash has dominated this world for a decade, and one can assume that it’s universally installed. As beloved as it may be by graphic designers, Flash remains difficult to program, notwithstanding recent advances from Adobe.

In sharp contrast, Microsoft’s Silverlight technology has an outstanding development story. Designers can use Microsoft’s Expression tools for graphical workflow, while developers use the familiar and powerful features of Visual Studio. For the UI, Silverlight uses the Windows Presentation Framework, for which there are many excellent educational resources.

The need to install a runtime has until now been a legitimate obstacle to the adoption of similar tools, but Silverlight appears to have achieved its goal of a small download and a speedy install. In a corporate environment—especially a Microsoft-powered one—it’s hard to see the runtime installation being a barrier to Silverlight.

Take small steps
One of the few practices that can be recommended without caveats is incremental delivery. There is simply no legitimate debate on this: The best way to deliver a beautiful and appreciated piece of software in 12 months is to deliver an ugly and insufficient piece of software in two months, a slightly less ugly and insufficient delivery two months after that, and so on. That doesn’t necessarily mean that one actually deploys the software broadly; the training costs and process changes could be prohibitive. But the feedback from real customers that are looking at real data and seeing real application flow is invariably both infuriating (“We talked about that specifically!”) and gratifying (“You like it! You really like it!”).

Some developers would say that two months is 59 days too long. Although truly continuous deployment to a representative user may have advantages such as a higher emotional investment, delivery cycles of a month or two serve two purposes: first, to perform the crucial functions of reassuring the client that progress is being made; and second, to catch major mistakes before any great investment has been made.

Two months is probably pushing the outer limits of an incremental delivery cycle; in an unscientific poll I recently conducted on my Web site, a delivery cycle of 60 days or less was one of the highest-rated practices, while longer delivery cycles were the lowest-rated.

Incremental delivery has additional benefits. Until recently, the process of deployment—compiling all the sources from scratch, creating all the websites and virtual directories, installing and initializes the databases, and so forth—was not given a great deal of attention, and was often a source of delays and misery. Short delivery cycles force teams to give deployment its due. With customers getting deployments every few weeks, it’s hard to ignore the benefits of continuous integration (CI) tools such as the Team Build 2008 component of Microsoft Team Foundation Server (or from FOSS such as CruiseControl.NET, available at confluence.public.thoughtworks.org/display/CCNET).

Under shorter development cycles, it becomes less clear that the formal discipline of project management, with its associated Gantt and PERT charts, is appropriate. Tools such as Microsoft Project, although powerful, do a poor job of modeling software development. Software development is not just cyclical but recursive, or perhaps fractal; tasks are composed of subtasks that themselves may be composed of further tasks. Formal project tracking was likewise not terribly popular with the self-selecting people who answered my poll, coming in at the low end of the “moderately important” practices.

Software development generates a tremendous amount of discrete tasks, and short delivery cycles require constant monitoring and triage of features, defects and improvements. Visual Studio Team System has built-in support for Outlook-based task tracking and a offers a configurable project portal for viewing the resulting data. Atlassian’s JIRA is another highly regarded tool for managing project tasks, but it does not have the tight integration with Outlook of VS Team System.

Yet another benefit of incremental delivery is that it promotes the creation of software modules rather than a monolithic application that has many internal moving parts. Practitioners don’t fret nearly as much as they did a decade ago about application architecture, and “big design up front” is considered an epithet, not a compliment.

Instead, there’s a general willingness to rely on SOA, which Sam Gentile, a speaker and independent consultant, says emphasizes “encapsulating application logic within atomic services that interact via a common communications protocol.” The focus, Gentile notes, is on the message rather than “the implementation, platform or runtime of the service itself.”

SOA is not linked to any technology stack, but Microsoft certainly encourages developers to use Windows Communication Foundation (WCF). Others would say that the World Wide Web itself has proved HTTP to be robust enough for, well, the Web, and that one should marry HTTP with the Web’s REST architectural principle for guidance. (WCF supports RESTful approaches, but the vast majority of REST discussions assume HTTP transport.)

Despite all the talk of software product lines and software factories, most corporate software development is done in the service of one or a few software applications. To the extent that new projects come along, they are more often integration projects rather than green-field opportunities. Accordingly, the week-in, week-out reality of corporate development teams is spent in the construction phase.

This is where unit testing, the signature “better practice” of the new century, has taken hold. Unit testing is the practice of continually adding large numbers of small, self-contained tests that directly exercise functionality—for instance, that a sub-total and taxes correctly sum to a total. “Test runner” programs or libraries, rather than starting from scratch and running the whole application for every test, load only the classes necessary to exercise the functionality. Whereas a black-box test that runs an application by simulating mouse-clicks and text entry might take minutes to reach a feature, a unit test of the same feature might be expected to load and execute in under a second. There are several test runners available for .NET developers: Visual Studio 2008 Professional Edition now includes unit-testing support formerly only available in VS Team System, while NUnit is a popular FOSS alternative.

The key process innovation of unit testing is that it puts quality front and center in the development process, rather than leaving it as someone else’s job. The intensely detail-oriented nature of programming makes it all too easy for developers to accomplish a difficult sub-task and wrongly conclude they have finished their work. Without automated testing, developers will often test merely a single path through the code, or even make a change without testing because it “must be” the problem. After a short learning curve, unit testing is widely perceived as speeding up programmer productivity by increasing turnaround and confidence in one’s changes.

Unit testing is closely associated with an emphasis on writing the minimal amount of code needed to satisfy the task or test at hand, in direct contrast to the emphasis on program structure that prevailed in the 1990s. The phrase “You Ain’t Gonna Need It” (YAGNI) is associated with the emphasis on functioning code and was the highest-rated practice in my poll. The triumph of YAGNI is in many ways a vindication of Microsoft’s long-held philosophy that code, not bubbles and arrows, is what’s most important about a program.

The problem with YAGNI is that good programs need abstractions and generalizations. You don’t want to have a shipping-charge function that works with US dollars, another that works with Canadian dollars and a third that works with euros. YAGNI needs to be paired with the talent and ability to refactor an initial implementation into a more general one. Therefore, YAGNI ought to be paired with DRY (“Don’t Repeat Yourself”), a phrase intended to capture the practice of refactoring towards generalities. Although Visual Studio 2008 has a handful of automatic refactoring functions, third-party applications such as DevExpress’ Refactor Pro and JetBrains’ ReSharper provide an embarrassment of riches when it come to restructuring code.

This brings us back to CI, another top-scorer in my poll. CI tools hook into the version control system and activate a build script every time a check-in takes place. CI as practiced today is not just about making sure that all the code compiles, links and loads, but is almost always thought of as involving at least “smoke tests” that ensure that the system is responsive to basic inputs. (Incidentally, version control is not listed as a best practice, because if your team isn’t using version control, you have bigger worries than what practices are best.)

In a team combining these top-scoring practices of incremental delivery, unit-testing, YAGNI, DRY and CI, there’s a natural rhythm of expressing a task’s requirements as a series of unit tests, and as new unit tests are created and passed, doing an increasingly rigorous version control check-in. Since unit tests are relatively small and discrete, it becomes rare to have a day pass without seeing a check-in from every active developer. In such teams, program managers no longer have to fear programmers “going dark,” but instead have to come up with ways to manage a relatively high volume of incoming task-related data. Burn-down charts and related techniques use such data to provide better tracking and delivery estimation than has generally been achievable in the past.

Microsoft, of course, provides a tremendous amount of guidance on both specific technologies and development processes. There are the half-demonstration, half-prescription (but often quite complex) .NET Application Blocks, the “patterns & practices” developer center, MSDN, conferences, et cetera. These resources corral the thinking of many of the very top minds in the development community. However, Microsoft’s understandable promotion of its own emerging technologies can make it very difficult to properly weigh the risk associated with them. After all, MSDN is not in the habit of saying, “This library is more complex than it should be,” or, “To be honest, this third-party tool is better than Microsoft’s.”

The self-named “ALT.NET” community has coalesced in the past year or so to represent a point of view that embraces the Microsoft platform for development, but it is more ready to acknowledge the benefits of third-party and FOSS tools and libraries. Unfortunately, the clear benefits of such a viewpoint have been drowned out recently by a kerfuffle over the appropriateness of the tone of some community members.

Although some voices in the ALT.NET community may be overly confrontational and holier-than-thou, it’s generally a good source for independent voices speaking to important issues.

People who care deeply about building great software and delivering value to customers will always have strong opinions. There are too many failures, too many myths and too much complexity for it to be otherwise. In the short history of our profession, what has been considered the best in one decade has generally fallen by the wayside in the next.

Agility is this decade’s buzzword for what’s desired in software development: the ability to rapidly deliver value, especially in the face of a changing competitive environment. In contrast to previous approaches, what many now view as better practices put one both closer to the code and closer to the customer. This is not to say that there is no place for object diagrams and the occasional Gantt chart, but a higher value is placed on daily progress and delivering a better-than-last-time application to the customer as frequently as possible. The apparent conclusion remains that the best way to run a marathon is to concentrate on putting one foot in front of the other.

Related Search Term(s): Flash, .NET, Silverlight, software development, Visual Studio, Adobe, Microsoft

Share this link: http://www.sdtimes.com/link/32678

EMAIL THIS ARTICLE

SEND FEEDBACK

MORE SPECIAL REPORTS