Change Management

In Frameworks We Trust (and that could be a problem)

Bola Rotibi looks at the evolution of software development frameworks and some of the good, and bad, that they've delivered over the years.

• By Bola Rotibi
• 06/22/2010

Welcome to our newest column, called Change Management, focused on the multi-faceted challenge of software development and delivery. Each month veteran industry analyst Bola Rotibi will bring her expertise in the arena of software development, delivery and lifecycle management to help readers understand the trends of the day and to make better decisions on the job. Rotibi was an analyst for both MWD Advisors and Ovum, prior to becoming research director of Creative Intelligence Consulting.

In the general economic gloom, the money-saving, innovation-driving optimism provided by software technology remains a definite ray of light in the business community. There is real excitement about the applications that developers are able to build using the latest software technologies and tools, along with the platforms that they can target and the innovations and efficiencies that they can deliver to their business organizations.

With the advances in software technology and the overall maturity and pervasiveness of software, developers have never had it so good.

But these benefits come with a downside: with so much at their disposal, never have developers come under so much pressure to deliver so much for so little. The lot of the developer and the development manager is not always something to be relish.

Too often we tend to generalize the term Developer, when in reality this is a big tent, covering everything from low level coders writing natively for complex systems to high level script writers choreographing mash-ups and Web services. Developers come in all shapes and sizes and with different skill levels and focus. Not all are capable of maximizing the benefits of the technology on hand, especially when working under deadline and with spotty training and support.

It is in this climate of conflicting challenges and increasing time and money pressure that frameworks have come into their own.

Not that frameworks are anything new. In fact, frameworks have been around for many decades in various formats. The software industry has a checkered history of producing multiple platforms, in-and-out of fashion software coding languages and scripts, heterogeneous environments, rapid evolution and changing architectural models. The barrier to entry for many without managed frameworks and tools would have been high and in some cases insurmountable.

Development frameworks for the most part offer pre-built components, libraries and a high level development/configuration layer to protect developers from issues associated with complex code execution, infrastructure 'plumbing' or technology integration. In many cases they remove the need to code solutions to common application functions and implementations.

Frameworks have helped drive and grow the software industry by opening it up to a wider audience of developers and application initiators, enabling them to build a broader range of applications productively and more efficiently. One need only look at the plethora of smart phone application frameworks and SDKs that has made is cost effective for many people to have their ideas turned into working mobile applications. Add to this the application stores that make the ‘go-to-market' channel more accessible, and the opportunity for revenue generating mobile applications suddenly opens up.

In short, frameworks have helped software to no longer be the preserve of the highly skilled. They have empowered existing developers by giving access to technologies and approaches previously too complex or expensive to consider and opened up new opportunities and application capabilities. New and advancing software technologies and architectural models and platforms such as cloud computing, virtualization and the highly complex world of embedded software systems are set to stretch the capabilities of developers again. And with ever increasing pressures on delivery schedules and code quality, frameworks are positioned to become more important than ever.

The vendor community has long been wise to the power and benefits of frameworks for bringing key programming methods to the masses. There were the 4GLs and CASE tools of the 80s, as well as the multitude of SDKs and APIs for managed development environments from the likes of Microsoft with its .NET framework, SpringSource with its Spring platform for Java development and Compuware with Uniface. These approaches help raise the productivity and efficiency of developers as they integrate with key software technologies. Most recently, Microsoft launched .NET Framework 4, which allows developers to reuse existing .NET skills and develop directly for Microsoft's Windows Azure cloud platform.

The Dark Side of Frameworks
But frameworks are not a silver bullet to time-stressed software delivery teams, and they do have a downside. One, moreover, that could jeopardize future productivity, drag down performance and prevent businesses from understanding the true value of a well architected software application.

Frameworks that abstract the user from more challenging construction issues can encourage a ‘throw away' mentality, where little thought goes into long term structure and maintenance. When this occurs, developers leave themselves wide open for technical debt where the lack of design makes further changes harder in the future.

The presence of frameworks that not only raise development productivity but can be used to deliver solutions quickly has another downside. By removing the need for intense planning, they can devalue the software development process and make activities related to architecture and design an afterthought for some decision makers. The notion of building up technical debt is once again lost as clients raise their delivery expectations, leaving a productivity and performance-drag time bomb for the future, along with quality holes when the load shifts dramatically.

Nor does a framework mean complete abdication of code development responsibility. While most commercial and open source frameworks are in themselves well developed, they do not always work flawlessly in all scenarios. Microsoft's LINQ (Language Integrated Query) component, part of the .NET Framework, provides powerfully productive native data querying capabilities to the .NET languages, supporting developers by generating the queries programmatically. However in some cases it may be necessary and more efficient for the developer to override what the framework does with a custom developed query.

Architectural Approaches
There is a two way relationship between architecture and frameworks. Architecture represents the relationships, dependencies, design patterns and rules of interacting components and systems based on design patterns, best practices, policies and rules. In some cases the differential between the two is being squeezed as frameworks help decide the best architecture to be employed, with developers simply specifying the object in question. But as new technology and platform models emerge and take time to mature, architecture considerations will always be a very necessary concern, no matter the sophistication of frameworks.

The Cloud platform presents data caching, storage and consistency concerns that will force developers to think more carefully about their data and messaging models. It will require them to do so in ways that they may not have done in the past. There are frameworks already in place that obfuscate some of the challenges of cloud development. Salesforce.com's Platform-as-a-Service offers a different approach to software application development and to acquiring and delivering development platforms and services. Others vendors are in the wings looking to deliver their own PaaS products.

However not all these middle-tier frameworks have yet to fully engage the management, instrumentation and monitoring facilities to give developers insight to improve their applications -- critical for opaque systems owned by third parties in the cloud. Nor are such frameworks appropriate for all forms of application development.

Ultimately, frameworks offer a path to developer productivity and speedy delivery of application code. But it is architecture and good planning that ensures that development productivity can be sustained and technical debt contained or minimized.

You don't need to be an architect to make design a worthwhile contribution to code development, even when it is delivered through a framework.