Application Development During Uncertain Times

The world's financial markets have faced extreme challenges the last few months. As the subprime mortgage fiasco in the US evolved into a worldwide financial disaster, we've seen major companies like Lehman Brothers and Wachovia Bank go out of business, AIG, Fannie Mae, and Freddie Mac get nationalized with more to come.

The de-leveraging of financial assets is happening at the personal level with mortgages and just beginning at the corporate level where companies have grown on cheap debt for the past decade. The extreme turmoil in financial markets is hitting the real economy and everyone is looking to economize.

As application developers, we've always been constrained by resources, time, and budgets, so that's not new. What's new is the heightened focus on this, combined with the rapidly changing environment. Sales forecasts, earnings estimates, and future budgets are all questionable when so much uncertainty exists.

Fortunately, application developers can use many techniques to save money and make themselves more valuable and productive. We'll discuss some of these and their tradeoffs.

A 50% solution this month may be worth more than a 100% solution in six months

The need to create applications rapidly and deploy them is heightened during times of economic turmoil. Organizations that quickly respond to change to preserve one's place or take advantage of opportunities others can't, will gain a competitive edge and provide better service. A strategy that does this quickly and cheaply is critical to survival.

For a significant number of situations, there's no time to spend a great deal of time in traditional application up-front detailed design, development, then deployment processes.

A more iterative process where you create an initial solution or prototype, let users try it, then redesign and refine based on feedback is more powerful. We wouldn't recommend this for mission critical solutions, but for standard non-enterprise applications where the "right answer" constantly changes, this is quite appropriate and it applies to all platforms.

The advantage of getting a partial solution into users' hands more quickly is that you can respond to their needs based on their use of the system. Original features that may be very costly to implement, may actually not be so important once users actually run the program.

In many cases, people don't know what features they really need until they use the system. That's what makes the traditional up-front design effort so costly -- sure I thought I wanted the features that way when I designed it, but after using it, I really wanted something else but could never know that upfront.

The 100% solution may be irrelevant when it's done

Even "perfectly" designed and developed applications may become useless for reasons beyond your control. The changing economy, new regulations, changing customers, products, or services, etc. can all make a "great" application irrelevant. Being able to create something quickly, get it in use, and adjust it "on the fly" is a powerful skill and philosophy. Especially in these uncertain times.

Every organization faces a wide range of application development challenges. Some require enterprise level solutions, while others are best handled by front-line information workers.

The more information workers can take care of their own needs, the more value application developers can provide to the problems beyond that. With more and more power on individual desktops and networks, information workers can accomplish many tasks themselves. We believe they should do so. Whether it's a sophisticated Microsoft Excel spreadsheet or Microsoft Access database, end users can create and modify their own solutions to quickly respond to their needs.

Anyone who has relied on someone else to design a data entry screen or report and experienced the hassles of adjusting columns to get it "just right" knows the frustrations of having someone else try to understand and do what you want. Let's not get in the way of individual efforts.

End users will create solutions that are a mess and will be expensive and painful to fix later.

So what? End users creating solutions that violate standards or "best practices" is not new. In fact, one should expect that if they're productive, they'll create even more messes in the future. That shouldn't be surprising.

The issue about "expensive and painful to fix" is what we dispute. Sure, a particular application may have been done better if it were better designed by a professional developer from the beginning. And no one likes fixing someone else's work. But the value of having end users and power users create their own solutions is that they'll:

• Create a lot of solutions on their own
• Solve a lot of their own problems
• Spend time creating solutions that become useless (not because of the application but because of change in business, regulations, etc.)
• Seek professional help when they've reached their limits

Most organizations don't have the IT resources to solve everyone's application needs. So rather than trying to build every solution for them:

• Train them to handle what they can
• Train them to recognize when they get over their heads
• Be ready to provide professional support when needed

The last part is critical. Application developers should support end users when they need help, and never blame them for getting into the mess. We don't know what they've endured to get to where they are. Let's make it a team effort. And let's recognize all the applications we don't have to build, or build and throw away, because they've vetted those for us.

We should have designed it differently ("correctly") at the beginning...

In hindsight, it's easy to say that a different approach should have been taken. It's the old, "Had I known this was what I was supposed to build, I could have done it in a fraction of the time."

There's no argument about that. Yes, it would have been a lot easier to know that up front. But that misses the point.

The journey is what determined what features are important. Usually, nobody at the beginning was prescient enough to know this was the solution we wanted. If so, it doesn't make sense to even consider that, since that option didn't exist.

Sure, we should have invested more time and effort into what turned out to be an important application. But this misses the point that there were many applications being created "at the beginning" and not all of them would justify such a large upfront investment. Who can determine with certainty which applications are the winners? It's far better to invest smaller sums in multiple projects with the expectation that it may be sufficient for most of them and that some will require (justify) additional resources later.

Applications are like living beings. The survivors evolve, the bad ones go extinct. Some weak applications survive and some "great" applications die. It all depends on their environment. During rapidly changing economic times, the power of natural selection is ferocious. The point is to not fight the inevitable forces that cause applications to evolve. Anticipate this will happen no matter how well designed it is, and be ready to address it when users respond to their changing needs.

As for fixing the actual application built by end-users, this is where it's important to consider whether to tweak it or rewrite it. If we're going to salvage what exists, we should consider it a prototype, and invest some time to clean it up and institute some best practices.

If it's beyond repair, then we should still consider the existing application a prototype, and spend the time and effort to do it "right" from scratch. This isn't so bad, and is what we "wished" for originally.

The difference between doing it now versus originally is that this application has proven itself. It has users who are productively using it or parts of it; it has management support, and now justifies the additional investment. The likelihood that it will actually be used is also much higher than a new application without a track record.

It's a win-win situation because the next version will benefit from your professional expertise, offer more features, and be more robust. It's an opportunity for you to shine.

Overall, the goal is to maximize the return on your development investment. It can be a traditional financial return calculation, or improvements in quality or service, elimination of mistakes, etc. Whatever the metric, one has many choices for investing resources. The more we can minimize the risk of application development, the more successful we can be.

This means we not only want to be very productive, we want to create solutions that make an impact on our organizations. In today's rapidly changing environment, rather than betting the farm on an expensive large project, it's better to make many smaller investments. While there's an expectation that a certain portion will fail, some small solutions may solve the need completely, while the market decides and justifies which projects deserve more investment.

In a world where people are doing more with less, it's important to streamline processes. There's an art to developing applications that no one disputes. But even artists, or maybe especially artists, need structure to reach the finish line efficiently.

A big part of application development is exception handling. Whether it's cleaning and validating data, handling special cases, or testing on multiple platforms, developers are constantly uncovering new problems. It's critical to learn from these mistakes and to prevent them from recurring. Establishing lessons learned and best practices saves lots of time, money, and headaches, in additional to personal embarrassment.

Minimizing problems early in the process prevents them from becoming expensive issues later. In team environments, code reviews, learning from each other, and making sure standards are followed is critical. There's nothing worse than realizing a bad approach was not reviewed early and replicated throughout an application.

At FMS, we've strived to create solutions to help ourselves and our customers with their development processes in several areas:

Catching Development Errors Before You Ship

• Total Access Analyzer finds Best Practices to detect errors, suggestions, and performance tips in Access databases
• Total SQL Analyzer finds issues in SQL Server databases

Cleaning Up Existing Code

• Total Visual CodeTools cleans up your VBA and VB6 code so you can more easily read it and apply error handling and other features to deploy a more robust solution

Deploying and Maintaining Applications More Efficiently

• Total Access Admin lets you monitor your databases in real time
• Total Visual Agent makes sure you perform the system administration tasks (like backups and compacts) to support your applications
• Total Access Startup lets you launch your Access applications and deploy updates in a centralized manner

If your solution allows it, choosing a platform that evolves significantly over time lets you add new functionality at a fraction of the cost of developing it yourself. This is how solutions on Office, Excel, Access, SharePoint, CRM, etc. benefit over time. With each new version, new features can be added with minimal effort and cost.

While Java/J2EE and .NET solutions also benefit from enhancements to those environments, it's very different from a platform that provides higher level functionality. That's not to say these programming languages aren't appropriate. They are the best for many cases, and people are using frameworks to build applications rather than starting from scratch. These frameworks have driven down the cost of creating web applications tremendously over the past few years, and let developers focus on the functionality of the solution rather than the core infrastructure.

What's important to recognize is where each platform is best suited and use it appropriately in line with the costs and benefits of alternatives.

Beyond the platform, buying instead of building is an important part of increasing your productivity. Finding solutions whether it's on the web or desktop that let you add more features and be more productive offers a very high return on investment.

Extending Functionality

Some examples of solutions we've created at FMS to address complex problems that people don't want to build themselves include:

• Personalized email blaster with Total Access Emailer
• Professional source code libraries with Total .NET SourceBook and Total Visual SourceBook
• Number crunching statistical analysis with Total Access Statistics, Total SQL Statistics, and Total VB Statistics

Celebrating our 24th year in business, we've experienced many ups and downs of the software industry and economy. What we've learned is to always offer value to our customers. That means delivering solutions that cost significantly less than their impact, and helping people achieve their goals. Technology is a tool to provide better service, make more money, save lives, etc. It's not the goal. We want to create solutions that are powerful and used.

Doing more with less will be a major focus over the next few years. Combined with creating solutions in uncertain times, low cost, rapid development of productivity enhancing solutions will be in great demand. Make sure you're ready to do so and leverage the abilities of the people you serve in the process.

Good luck!