5 Tools all non-technical software founders should use

Many software companies are run by founders who are non-technical themselves. As long as they have a technical team that is strong and reliable things work out just fine. However, there are some tools that the non-technical founders can use to make the software development process even smoother. These are tools that the techies themselves use but many founders shy away from them thinking of them as something that is "too techie". A little time investment on learning the basics of these tools could bring in huge improvement to how the software is made and delivered. These tools can save time and money by communicating early feed-backs and decisions in the software development process.

In our experience as a software development consultancy that has helped dozens of startups all over the world build out their products there are some tools that are absolutely vital for all the stakeholders to use - techies or non-techies. We insist that our customers use them, we even run training sessions for non-technical stakeholders to learn the tools. 

Today I'll run through my list of top 5 tools that every software project stakeholder should learn and use.

1. Issue Tracker

This is the easiest one to use. All software team use an issue tracker (or at least that is the least we can hope for). There are numerous very good trackers out there, what you choose depends on your taste and need. There is, for example, reliable workhorses like Jira or Fogbugz or super simple trello or if your team is all for mods - trac; the list is really endless here and it doesn't matter what the exact tracker is as long as it serves the team's need. Whichever tool they are using it's relatively simple to learn for a non-technical user and then start using it to stay in touch with what the development team is working on. The tracker is perfect for putting in early feedback on features, keeping track of what feature gets done when and to communicate with the developers within the context of particular tasks.

It is hard to list all the benefits of bringing in all the stakeholders to the issue tracker. It simplifies pretty much all conversations, takes away all the nasty surprises of product demos and brings in feedback at the right time of the development process.

2. Wire-framing tool

Wire-framing or mockup tools let you draw pictures of software screens in a quick and dirty way. They are essential to get a quick version of the software that can be used to communicate features, test if they meet the requirement and also check if users can use them. Usually the design team within a software group uses it to get the Ux done and rest of the group just uses the output for their work. But if a stakeholder can use the tool then she can quickly draw up her own screens or make modifications to the exiting ones without waiting for a designer to do it. This speeds up the whole communications channel and makes it really easy for complex ideas to be fleshed out.

I remember one project that we picked up midway where the founder would painstakingly write up huge documents to describe features that he and his team wanted to be built. These documents would take several meetings to be explained properly and even then misunderstood by a few in the team. Inevitably this created a lot of friction. We introduced a simple wire-framing tool to the founder's team and almost magically the whole process transformed to something that was simple and fun. 

My favorite tool is, of course, balsamiq which is just perfect for non-technical people. But there are many others out there although some can be quite daunting :)

 3. Build and deployment tool

A build system lets anyone create a build of the software from the latest code and deploy it on a "staging" where it can tried out. This has to be setup by the technical team and every self respecting software team should have one setup for even the smallest of software projects.

Once it's setup, it's relatively easy for a non-technical user to learn how to "get a build" done. Usually a few button clicks in the right places does the trick. But this gives immense power to the stakeholder as it lets her get a view of the software at any time without a lengthy process involving the technical team. Essential for quick feedbacks or a sneak peek or even a pre-launch demo to prospective customers.

Many tools out there for this. Jenkins and Cruise Control are popular ones and very simple to use once setup, but there are others that are equally good. 

4. Performance monitoring tools

There are many tools that can test the performance of a software. These are essential for quality assurance team to test the software but are equally useful to a non-technical founder to gauge the quality of the software that is being delivered. These tools can give the stakeholders a list of issues that they can then prioritize and push for fixes from the development team.

The tool(s) to use depends on the nature of the application being built. Usually a few google searches land you to the right pages, but here are some that have proved the test of time. An old but faithful tool for testing the quality and performance of any web application is ySlow it gives you a nice list of things that needs fixings to make the site faster and also points out glaring mistakes which may not be so glaring at all to a non-techie. Other examples in this genre are Google PageSpeed, WebPageTest, Page Analyzer and the full of bells and whistle GTMetrix.

Great tool to keep your dev team on their toes :)

5. Code quality tester tools

Now I'm in contentious territory! These tools analyzes the actual code and rates it for quality. It identifies obvious mistakes, not so obvious bad practices even performance flaws in the algorithm. A non-technical founder may find it impossible to judge the quality of the code himself but he can utilize these tools get an idea about the code. In many ways these tools can act like auditors for him.

Again this requires technical team to set things up properly. But once done the actual analysis is a simple process. It is definitely worth the time investment. At the bare minimum a non-technical founder should insist on having such tools installed on the development environment and ask the team to use them.

Once again, many providers, but only a few that are outstanding. The tool to use also depends on the technology platform e.g. in the Microsoft world Resharper or FxCop are very good tools. Java world has many (as usual) e.g. findbugs, PMD, etc. Whatever the platform there's a code analysis tool that is just a google search away!

// This article is a reprint from our CTO's LinkedIn pulse