Reusable apps?

If you’ve ever developed an application or for an application, you’ve probably thought:

“This is fantastic! I bet everyone can take advantage of this. It’s generic, flexible, and sure to fit the needs of most!”

Then you decide to take the next step and share it with the world. A few weeks pass, your generic one-size-fits-all solution starts getting some traction, and then it happens: You start getting requests to change what you think is already a perfect app:

“Can you make this available for this OS/Platform?”

“This is great! Could you also add this or that functionality?”

“This is ridiculous; how can your solution not handle this case?”

Been there? Don’t feel bad. Most of us have been guilty of what is called the delusion of reuse. Before doing our due diligence, we post it out there for the world to see and use. According to Robert Glass in “Facts and Fallacies of Software Engineering”, the due diligence for reusable components comes with two different considerations:

  1. It is three times as difficult to build reusable components as single use components.
  2. Before categorizing a component as reusable, it should be thoroughly tried out by three different audiences first.

This can seem like a bit much, but having created some of these myself, I can attest to both of these points.

If you’re thinking about creating reusable apps, components, or even functionality, make sure you keep the below advice in mind when creating a reusable component. (I personally love building reusable component and applications.) A few things you must consider include:

    1. Build your reusable components with change in mind. Final” is rarely a label applied to any component or solution. Create your component assuming it will be used, and perhaps even extended by others.
    2. Have a specific end-goal in mind for your component. Sometimes, a component can be simple, like a plug-in that extends an existing functionality. Other times, they can be fully fledged solutions, such as those in the Appian Case Management Framework. Example goals could be:
      1. Accelerate Time to Market
      2. Reduce time and complexity of creating a specific solution from scratch
      3. Designed with extensibility and flexibility in mind
    3. Test your component in at least three different projects. You will get three different sets of feedback, ideas, and comments. This will enable you to put the finishing touches to your
    4. Build it on a platform that is built for change. The need to re-format, re-design, create different interfaces for different end-points, security, identity management, flexibility and design can all be real deterrents for progress. Sometimes it seems you cannot build on your solution, as you need to be constantly focusing on these other considerations. By leveraging a platform such as Appian to build your reusable solutions and components, you’ll be able to focus on making sure your solution meets your objectives and your user’s needs, confident that the rest is handled by the platform.

In summary, building reusable components is not easy. It takes experience, feedback from multiple sources, and the right idea. However, the difference between a success and failure could very well be in the platform you use to build on. At Appian we believe in empowering our designers to create enterprise grade custom applications by providing a single-stop platform for all their needs. We believe in a platform that makes app building easy, generates powerful, secure apps that work from any device, and is made with change in mind.

To learn more about how to build apps that keep pace with the demands of today’s enterprise, and the fast changing technological landscape, I invite you to take a look at our Whitepaper on The Modern Enterprise Application Platform.

– Jorge Sanchez, Director, Product