Connect with Us
Thank you! Thank you! I just finished reading this document, which was part of a link in the recent Buzz newsletter. I have printed it for others to read, especially those skeptical on the powers of Access and its capabilities.
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.
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.
Empowering Information Workers
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.
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.
Payback from Information Worker Empowerment
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:
Most organizations don't have the IT resources to solve everyone's application needs. So rather than trying to build every solution for them:
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.
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.
Enhancing Existing Applications
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.
Return on Investment
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
Cleaning Up Existing Code
Deploying and Maintaining Applications More Efficiently
Buy versus Build
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.
Some examples of solutions we've created at FMS to address complex problems that people don't want to build themselves include:
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.
About the Author
Luke Chung, President and Founder of FMS, Inc. (www.fmsinc.com). FMS is the leading provider of 3rd party products for Microsoft Access, SQL Server, Visual Studio .NET and VB6. FMS also provides custom application development and also has a group offering solutions for the law enforcement and intelligence communities.