8 rules for delivering highly successful applications

In my 18-year career as a software developer, I have had the opportunity to work with some great teams, clients, and on some amazing technology. I worked on projects for BMW at the dawn of the Internet video age and built enterprise applications for the financial industry. My role on these projects was either developer, architect, tech lead, or a combination of all three. Every project has its unique challenges, but here are a few things I’ve learned that have always led to success.

1. One team, one boat

A software development project team is often comprised of diverse departments: business, UX, designers, QA, project management, developers, and network/dev operations. Do they have the same goals and expectations? Can they all articulate the goals? Differences in agendas and definitions end up creating wasted time, time spent navigating political and personal battles. Not to mention confusion and chaos. Get in the boat and grab an oar, or a towel!

[aditude-amp id="flyingcarpet" targeting='{"env":"staging","page_type":"article","post_id":1923155,"post_type":"guest","post_chan":"none","tags":null,"ai":false,"category":"none","all_categories":"dev,entrepreneur,","session":"B"}']

2. Test, learn, and refine

Successful development is an iterative process. Building something that is “good enough” and releasing a beta or MVP allows you to learn and put effort where it needs to be. You test, learn, and refine. Smoke and mirrors and voodoo magic are okay. Allowing users to touch and see something that actually works confirms or disproves your design/UX/development direction. Rapid deployment keeps the project moving forward faster. You’re not just testing the product, you’re building the process. Spend time early in the project to get an automated deployment process set up. This will allow your team to get builds out quickly and consistently.

3. Throw away code

Yes, throw code away. It is necessary on the path to building a great product. This is more psychological than technical. Sure, it’s hard to think that what you developed and the time you spent were wasted. They’re not wasted. A tremendous amount of learning is done through this process. Refactoring/cleaning up goes much faster the second time, and it becomes that much better because you know exactly what you need to build.

4. Development/IT is not king

Chances are you are working on projects with a multi-disciplinary team. See point 1 above, and remember you’re all in the same boat. Respect your teammates and their roles. Help them get it. Do not get frustrated when a PM asks for status. When QA says there is an issue, it means they have found a bug — listen. You can only say it “works on my machine” so many times. Everyone’s role brings value to the project.

5. Defend less, listen more

You know that the only way to get better is to learn from your mistakes, but you don’t want to take criticism from that person. I have made plenty of development and operational mistakes, and each time I learned what not to do the next time. It might be something like forgetting to close DB connections. Or maybe it forced me to learn a new tool or corporate ECR process. The best part of working with new people and backgrounds is they bring different perspectives and experiences. If a teammate suggests changing your code structure to make it more testable or warns of pitfalls if you don’t strongly type your variables, it’s probably because he or she has learned from their past mistakes.

6. UX/UI/Design is your equal

Coming from a technical background, it was hard to understand/swallow this at first. I learned early in my career that if you build something that no one wants to use, all the effort spent building a great foundation and infrastructure does not matter. When I first started at the agency and built my first page for BMW showing the specs for a new X3, I had designers over my shoulder reviewing the page. In my eyes, it looked great; but the designer shredded it in less than 30 seconds. It was my first time being pixel pushed, but at that point I realized this is what separates the okays from the greats and I never looked back. Great looking UI and UX is what users see; they do not see unit tests and code architecture patterns. The technical implementation is what makes the application work great for current and future needs, but without a great user experience, you won’t attract the users there to see it.

7. Know when to optimize

Knowing when to optimize can be one of the most debated topics. Building the Cadillac from day one with several layers of abstractions, 95% unit test coverage is usually the go-to plan. These sorts of optimizations and architectural patterns are all necessary for building a great product, but knowing when to implement them is important. The challenge with doing all this work up front is you start losing your ability to be flexible and will likely spend many hours on something that may or may not make the cut. Take your learnings from other projects, build a decent base, but be okay knowing you will have to come back and refactor to make it better later. I have always enjoyed optimizing code. It’s even more satisfying when you have nailed the initial goals and are now taking it to Cadillac level.

8. Use analytics from day one

Making assumptions about how the application should work from non-actual users can take your application down the wrong path right away. I have product owners and developers say, “I know what the users want and what devices and browsers they are using.” They could be right, but let’s validate the gut feelings and assumptions with real numbers. A way-back-machine example of this is when developers would ask, “Why do we need to build this for IE? It sucks, and no one uses it.” My response would be to take a look at the web analytics, which could show that 80% of the users coming to the site were on IE and only 20% were on Firefox. That’s a two-second, data-backed, resolution. In most cases, the developers and business owners are not the actual users of the app.

And like any good process, let’s go back to the start and assess: Is your team in the same boat? Do you have the right team? With the right understanding? If you want to ask about that, throw down some questions here. Thanks.

[aditude-amp id="medium1" targeting='{"env":"staging","page_type":"article","post_id":1923155,"post_type":"guest","post_chan":"none","tags":null,"ai":false,"category":"none","all_categories":"dev,entrepreneur,","session":"B"}']

George Hilal is executive VP of Technology at Duffy.