Five Tips for Faster App Development

…though they’re probably not what you expect.

Early on in my IT career a co-worker (Let’s call him Bob) told me that in creating anything there are three variables: Fast, Good and Cheap. “You can pick any two,” Bob told me.

Thus I was introduced to the Iron Triangle of project management. (AKA The Triple Constant, AKA The Project Management Triangle, AKA Johnny Fingers. Okay — I made that last one up.)

The triangle served to demonstrate that you can get things fast and cheap, but you sacrifice quality. You can get things fast with quality but it will cost you. Or you can get things quality and cheap, but delivery will be slow. So, when approaching project budgets, timelines, and hiring expertise one ends up constantly tweaking variables to try and get things done quickly, done well and done within the budgetary constraints.

Let’s talk about ways to get software development done faster at the project level.

There are many factors at play in software development, even the simplest projects. (If you think that the distractions of Facebook and Twitter are new to the 21st century, you’ve never lost hours of dev time to co-workers caught up in a Usenet flame-war.) The focus of this post is team-projects. We will have to look at tips for solo projects in another article, but there may be some usefulness in these tips for you independent code-slingers out there.

Prioritize the Right Requirements

Your project is going to have limits. Whether these are budgetary or time-related, there is always that hidden limit of quality lurking out there as well. How can you know what the right features are to prioritize in your development project?

We use a process called Envisioning which precedes the actual development work. Through this process we help visualize the scope of the project, the interrelation of the various components and concepts, and the minimal working functions upon which we can build further layers of complexity.

Envisioning has become a key part of our Agile Development strategy and it ensures that everyone from the stakeholders to the developers understands what they’re working on. From this process we can develop our User Stories which will direct the actual daily goals of the developers. Our work is broken up into short sprints which end in a Playback (a public demonstration of the code’s progress) so that everyone can see what has been accomplished. We also share our progress through a burn-down chart which shows how we’re progressing through the sprint so that everyone involved can figure out what to focus on to reach the objectives. Much of this is, at least in theory, part of Agile Development but we find that by adding the Envisioning process up front, we have a roadmap to guide us through the entire project and it is easier to visualize where particular features are going to have prerequisites that might not have been obvious otherwise.

Firebreak your Scope Creep

Stopping scope creep can be difficult because usually the requests which are pushing out your timeline are also the requests are urgently needed by someone. Why is scope creep pushing out your delivery date? Shouldn’t all this stuff have been thought of in the planning phase?

The reality is that most projects get pressure to add features at the most inopportune times. This is where good communication and honesty are critical. Project managers who say “yes” to everything without adding “but, this will affect the delivery timeline” are being disingenuous and it will come back to bite the project.

A good project manager is going to be honest about timelines at the same time as serving the needs of the business owners. Track your User Stories in a tool that lets you share progress with the stakeholders. Show them how adding stories and feature requests affects timeline of the project. Have them weigh the needs of the project against the value of the components or features being added.

Manage the expectations of the stakeholders and the executives. Your goal is to give the best product you can, within the time constraints and still provide user interface or feature requests that will improve the product throughout the development cycle.

Use software sprints to break up the project into chunks that provide deliverable features that can be demonstrated at the end of each cycle. This lets the users know their needs are being considered, and through the playback process everyone can see what they’re getting and watch it evolve through completion.

By using sprints, user stories and a burndown chart you can show during the planning phase of each sprint how various features choices will affect either the delivery date, the other features included, or the price of the project. Use the backlog as a corral for features that are lower priority and have your team fall back on those if they get ahead of the build schedule.

The Iron Triangle is always out there. Pretending otherwise is the surest way to be crushed by its implacable weight.

Don’t waste your time on boilerplate

If you’ve been on a few software projects, by now you should have noticed that there are portions of every engagement that are basically the same. For example, CReate/Update/Delete (CRUD) services are going to be needed on any project. User authentication, Permissions, Menus, Navigation — there are aspects of these projects that have to be banged out over and over again.

Why do that work repeatedly?

There are a few ways to get around repeating this work. One way is to develop libraries within whatever development framework you’re using and then to import that “boiler-plate” code into each new project (along with any improvements you’ve accreted with experience and time) so that you can skip on to the more bespoke aspects of your project.

Another way, one we’re really enjoying here at Apex, is to use a tool like Apex Designer that brings that boilerplate online with each project you create. This allows much quicker delivery — and since we’re also using Apex Designer for our envisioning and User Story management, by way of our Apex User Story Manager (AUSM), we can speed up project delivery significantly which helps manage that Iron Triangle from the very start of the project.

Use the 80/20 Rule on Design Choices

Nobody wants an ugly program, but spending too much time on elegance can cost you on functionality. We advise you to use the 80/20 rule when making decisions around design elements.

The 80/20 Rule — AKA The Pareto Principle — suggests that the majority of the usefulness of your application will come from only about 20% of the features. Think carefully about that when prioritizing features because if you spend too much time on features that almost nobody will use, you end up with a clunky mess that only serves the people pressing for those obscure feature and not the majority of users.

I’ve mentioned it before in this article, but it is worth bringing up again. The minimum feature set — the minimum functional program — is what you must deliver to have a successful project. But nobody wants a minimum functioning product — they want the minimum-plus. The plus here is whatever they as individuals also want and that’s where you need to work carefully to make sure that your project is not driven to waste effort on non-essential features when you haven’t finished the essential ones.

Leverage Standards

You’ve probably heard the phrase “don’t reinvent the wheel.” Somehow, despite the obvious wisdom of this cliche, it still happens again and again. In software dev projects, the most common cause is that some features are needed which don’t exist in the tools you normally use so your team spends time coding out solutions… only to discover later that these features already are neatly packaged in other libraries or frameworks you could have used.

Picking the right standards involves research, trend-analysis, an eye towards longevity and making a decision about whether the effort required to train your team up on the new platform is worth the investment in time and energy. There’s some art here. In a field where many feel like data can provide the “right” answer to any question, choosing platforms can be challenging.

But it’s worth the effort to get it right.

Failure to pick the right standards can lead to lots of issues around interoperability, missing features, effort required to get a solution working, security challenges and more. If your team works as developers but are partitioned off from the infrastructure team, you need to get them involved in the selection process. Don’t assume that the tools that meet your needs will be embraced or supported by everyone else. Talk to them first and confirm. Collaborate. You may even need to compromise in your selection to get past all the gatekeepers — but it is far better to have a reliable, future-minded set of development standards than to navigate a mad jungle of potentially conflicting tools.

Conclusions

You may have come to this article expecting it to be about how to use certain development tools more effectively, or tips and tricks to deploy with fewer errors. Those are also areas where speed and efficiencies can be found, but in a typical software project it can be these overarching up-front choices that have the greatest impact on how effectively your development project is delivered.

Speed. Quality. Price.

The Iron Triangle is always out there. How equilateral can you make it? That’s the challenge. If you’ve got some other tips or stories about your projects you’d like to share, let us know! We’d love to hear from you.