I want to talk about what startup founders/entrepreneurs do to build bad software for their business.
If you are interested in this post, you might be startup founder or business owner with a great app idea. You may already have a well thought-out business plan, and a solid marketing strategy to execute behind it.
You may not be tech savvy though. But you do have a general idea of the development process and what tech you need to implement. You just need someone with experience that can get it done.
It's important to find the right person of course. But first, you need to know what a good developer experience looks like. Not knowing the service you are supposed to be receiving can blind-side you.
Many clients come to me with horror stories about their previous developer.
Some devs are terrible at communication -- timezone differences aside.
Some devs start a project, then disappear.
Others don't have the experience, and they tell you they do (sometimes they think they actually do). They make a mess of things, and create buggy, unscalable work.
Entrepreneurs later realize after many years of slow progress, do-overs, and endless bug fixes, their "dirt cheap" developers become insanely expensive.
It's not the dev's fault completely, either. There's also things entrepreneurs do wrong.
I hope to point out some things that you as well as your developers are doing that is making your project fail.
I also hope to offer some tips on how you can improve, so you are in a better position to hire the right "Programming Ninja Expert Guru Person", or whatever.
See the signs!
Here is my list of top problems which are clear signs that your software project is on the road to failure.
Sign #1: You hire a dev you don't know
Your friend knows this guy, he's about 15 hours away in the other side of the globe.
He seems smart, and even though he hasn't worked in a team environment before, didn't show work samples, and gave no real proof that he knows what he's doing, you have a "gut feeling" about him, because he's a really nice guy.
Plus, your friend recommended him. Your friend is not a tech savvy person either, but you trust he makes good decisions about fields he doesn't know about.
Sign #2: You avoid experienced devs because they are pricey
You feel a Senior level developer is too expensive. You have to watch your budget after all! Two cheap Junior developers are still less than a Senior level developer, and they will do twice the work!
Sure, they haven't led a project. But look how cheap they are! Besides, you can guide them yourself, and with a little effort they will get it through the finish line.
It won't be "Senior dev" perfect, but it will save you tons of cash.
Sign #3: You don't have a process describing how to reach your goals
Your dev doesn't have a structured way of defining scope of work, scheduling releases, determining priorities, measuring their speed, enforcing project contribution guidelines, reviewing other devs' work, automating processes, and many other things.
They just plan a list of to-do items and determine their own priorities. New work is completed at irregular rates and feels incomplete. There doesn't seem to be a clear goal in mind with the work released.
You review the work and ask them to make updates. They push back saying the update will take too long, or will push the deadline further back.
You feel disappointed with the lack of order, confusion, and poor quality.
Sign #4: Your developer behaves like your employee
You created a document that describes what your app is about in detail. You added a list of features you would like such as social login, push notifications, database integration, messaging, etc...
There are flowcharts and wireframes for them to follow, and even references to other apps that have similar functionality to yours.
Your dev takes this initial information, and provides you with a quote. They also let you know they have enough information and are ready to get started with your project.
You are impressed that they did not ask you to clarify certain uses cases, what problem does your app hope to solve, who is your target market, how many users do you plan to have in the first year, and other important business-related questions that should direct the technical strategy.
They also did not push back much in the features or descriptions for your timeline, or how you hope to accomplish certain goals.
Since they haven't asked much, you figure your documentation was enough, and they must have understood right away. Your gut tells you something is wrong, but you assume it's fine because they are professionals.
Sign #5: Your communication with your dev is poor
You haven't heard from your dev in weeks. You figure they are working because they continue to charge you.
They reply 3 days after you DM them. They tell you all is fine and they will have something for you soon.
You're sure if they have any question they will reach out to you. Once something is ready for you to review, you can then see how things are going. You'll just wait patiently.
Sign #6: You manage the project yourself
Agile method-what? User stories? Scoring sessions? Standups? Sprint planning? Roadmaps? Scoping? This is so unnecessary. Only large enterprise projects need this level of planning.
Your app is simple, and easy to understand by anyone.
You choose to just manage the project on your own.
You don't understand the drop on communication from your developers, when you assign a task.
They seem to work extra slow, the tasks are not complete as you described them, and get bogged down by details they should have gotten right already.
You get the sense that they are not understanding the scope or reason for the ticket, and you feel forced to "micro-manage" them too much.
Sign #7: You are a perfectionist
Your app features are all equally important and refuse to remove any of them to lower the development timeline for "version 1".
You already know what your target users want because you did extensive market research.
You refuse to lower your app's quality at the cost of bringing it to market quickly, because you feel it will affect your brand.
It's not you it's us
Like I said it's an issue on both sides.
There are underqualified developers running your projects, and entrepreneurs without the experience to know how it should run from the start.
If you relate to this, let's talk about how to avoid the signs.
Tip #1: Vet your developers carefully
Don't take anyone's word (friend or developer) for the experience they claim. Ask questions that will let you better understand their experience. Below are some question you might want to ask (there are many more you can ask, these are just a few).
How long have you worked in the field?
This is a pretty basic question. If you are looking for someone to lead your project, you should find someone with at the very least, 3 years total experience, in my opinion.
I don't mean 3 years experience in the tech you want to use, just 3 years in total development experience. Tech changes way too much, you should look for core experience and skill. This is a much better way to measure their experience.
Even so, they should have work experience similar to what you are looking to get done.
If they have been in the field less time, that's fine, so as long as you have someone to lead them. They probably don't have the experience to lead a project yet, unless they can demonstrate they can without any doubt.
Tell me about the apps you have developed in the past?
You want to know that they have done work similar to what you need, and are able to describe in some detail about their experience.
Viewing links to their work is not good enough. It leaves it up to you to guess at what they actually did.
Ask them for details. They don't need to get too technical, but they should be able to explain some key details about their work that gives you some confidence in them.
Side Note: This will also help you gauge their communication skills. They should be able to explain to you in plain english, without going over your head, what they have done and the impact it had on the project. You want to hire someone who you can communicate well with, since you will be working closely together. You don't want to work with someone who cannot describe development concerns to you in a way you can understand.
What has been your biggest challenge you have had to face on a project, and how did you resolve it?
I like to ask this question because it helps me understand what they consider to be a challenge, and how they think through problems.
For example, if their biggest challenge has been laying out a list of data, then you can tell they probably don't have much experience, because laying out data on a list is pretty common. They still may be hireable, but they should not lead the project.
If you are looking for a tech lead, their challenges should come from an architectural perspective -- the overall technical planning around the development.
Since these are broader ideas, they should be able to explain to you without getting too technical as well.
You want to look for challenges that are similar to the challenges you think your project has. If you have some use case concerns on your project, you might want to ask them how they would handle those cases, as a way to test them.
Can I see code samples of your work?
You need to know if they can write clean, scalable code that can be modified easily as your app grows, or if they create messy "spaghetti code" that is hard to modify and will burn through your budget.
You also need to know if their work feels over-engineered, or if it has an elegant feel to it.
This is pretty crucial, and one of the biggest problems I've found with problematic projects. The work is just not great, and needs huge re-writes.
Get help
It can be really tough to know if a dev is up to the task if you don't have that dev experience yourself to dig deep into their experience.
If you're having a hard time knowing if someone is a good fit, just hire an experienced consultant that can vet them for you. It will be worth the cost in the long run to hire someone who knows exactly what to look for, and how to ask the tough questions.
Tip #2: Hire a Senior Level developer
Why hire an experienced developer?
There is a drastic difference between experienced and inexperienced developers. The main difference is that inexperienced developers simply do not have the ability or know-how to build sustainable software.
A piece of software that is naively built can easily double or triple the cost of the entire project during its lifetime.
In contrast, while an experienced developer comes at a higher up-front cost, their experience will pay off in a big way in the end. Their years of experience in building applications lets them see issues way ahead of time. They can easily spot and fix bad architectural patterns that would otherwise become a nightmare down the road.
Experienced developers have failed enough to know what should and shouldn't be done in a project. They have made all the mistakes you don't want to make, many times over.
They are very efficient coders, and they have custom tooling and libraries to back them up as they work so their efforts are spent in the areas you need the most.
Devs with experience also typically have led teams already, and learned how to collaborate with developers of different personalities and temperaments. They also learned how to lead by example, share their knowledge, and not boss developers around.
Their experience is very valuable. The cost of an experienced developer in your corner, having that knowledge and skill available to your business is a great investment that can't be understated.
Should I even hire a Junior dev at all?
Yes! Again, Junior level developers in your team are great so as long as they are being led properly. Don't shy from hiring Juniors, they will definitely give you a lot of bang for your buck.
I recommend that each team of Junior devs are lead by a Senior team lead, who also assists in implementation, and can help in app architecture, recommending best coding practices, helping with code reviews, and determining high-level technical decisions.
If you feel a Senior dev is too expensive, then hire them only for tech leadership and/or project management portion, and not for the hands-on implementation work. That should lower their cost, and you still will benefit from their experience.
If you do have the budget, I do recommend one or a few Senior developers also assisting in implementation (doing the actual coding). They will bring high value this way by their efficiency, creating scalable work and by solving problems a lot faster and better than they do if they are only communicating their knowledge to Junior developers -- this is a huge win.
Tip #3: Stay organized
Any developer with experience will tell you, a major part of software development is organization.
At a high-level there is also tons to keep track of (features, bugs, tasks, components, designs, userflows, transaction flows, etc...).
Since there is so much to keep in mind, it takes a bit of practice and experience to organize things in a way that makes sense to everyone.
If you don't have a project management background, this may be difficult for you. And this can cause a lot of miscommunication between you and your developers.
As the product owner hiring a project lead, you should find a lead who can organize the project correctly. It is a big burden to put on yourself.
A good project lead will typically follow similar practices I describe below. There are more qualities of a good project lead, but this is just a small example of maybe the more important ones.
A good lead will organize and group tasks logically
The project lead should group tasks logically, with a hierarchy.
There are tasks that cover broad ideas (authentication, search, push notifications).
Some tasks track concepts within broad ideas (user registration flow, user roles, etc...)
Other tasks track details (implement UI registration modal, implement forgot password feature, add user admin role)
And you can break these down even more. The point is, there is a hierarchy. Tasks are organized in a logical order that is easy to identify and track.
A good lead will also try to centralize all project information into one location.
Discussions about a certain feature should remain in that ticket. Commits of work should be referenced in the ticket that commits belongs to. Links to supporting information should also be linked on the ticket.
Project-wide info should be linked at the project level. Things should be organized in ways that are logical, and require very little explaining to other team members.
The lead should use the right tools to bring all this together. Typically this is done with a decent project management tool, such as JIRA, or Pivotal Tracker, or maybe even Trello boards.
I personally use JIRA right now, it has everything I need to manage and track a project, and then some.
I'm not a fan of Trello, but I believe it may work for smaller projects.
It's not important what they use. The main point is, they need something that can track work, and group/organize them in ways that make sense to everyone.
Be aware if their project to-do items have no form, no logical order, and related notes are in multiple places without a true "single source of truth". These are the signs of disorder and confusion in a project.
A good project lead will favor faster releases over long drawn out releases
A good project lead will implement some form of the Agile method for software development, which is out of the scope of this post.
One of the concepts of Agile is releasing often. You don't want to wait too long to get features out to users.
Their feedback is valuable and you should view them as collaborators on your product, to help you understand what they really want, and how you can deliver that to them.
Long timelines work against you because you don't have a constant feedback that can direct your future features. It slows down your product's rate of improvement.
A good project lead will have a workflow that keeps your eyes on the goal
One big reason for this is to avoid distractions. In my opinion, one of the main distractions is bug fixing.
As product owners review the work that is done, they will inevitably find bugs. There is no escaping this, and depending on how complex a feature is, you might have a lot of bugs to get fixed.
Sprints
A common way to maintain a workflow structure is by using Sprints (another Agile concept). The project lead could make use of sprints as part of your worflow, to help with managing priorities and stay focused.
In a sprint, you create a range of time to commit to a goal. You prioritize tasks (and bugs) for the sprint, determine a common goal, and get working. You will not change course until your sprint is done.
If new bugs are found during the sprint, these are added to a backlog and are not worked on immediately. This keeps the developers focused on their goal for the sprint, and not on the bugs that are trickling in throughout the day.
Once the sprint is over, and it's time for a new one, the tasks and bugs will be prioritized again, and the process starts all over.
Of course, if there are bugs that need to be fixed right away, they are added to the sprint.
Using sprints is a very common way which is good to be aware of. It may not be the only way, but the point here is to have a structure that reduces distractions and keeps everyone on the same page, and focused.
QA Workflow
Hire a QA person if it's in your budget. As a product owner, you have better ways to use your precious time, than to check someone's work every day, and submit bug tickets.
A QA person will check all work that may be released, and inform each dev of any bugs that are found. The devs will fix and update way before you ever get a review link.
It's also good to mention that this reduces your stress level because you are not being bothered with the details of development.
Keeping your stress low will make a huge impact -- it's worth the investment.
Tip #4: Partner with developers
If you want to hire someone to lead your project, look for a developer who behaves like a partner, and not like an employee.
Partners will be proactive and will contribute to the project with ideas on increasing revenue or lowering costs.
They will also recommend the best tech for your business goals, and not just what they are comfortable in using, or what you suggest.
Aside from using their time, your dev should offer their knowledge and experience to better your business.
Tip #5: Communicate often
In my opinion, you should expect consistent communication from your devs, at least every couple of days to once a week, even if it is just a quick update.
You need to know how things are going, and what problems they are experiencing, so you are able to catch problems early, or re-align priorities.
Communication lets everyone know how that the project is moving, and keeps up morale.
You should also communicate and check in with your devs if you haven't spoken in a few days, just to make sure all is well. When devs feel you care and know you are there for them, they also care ?
Tip #6: Minimum Viable Product for the win
Keep your initial version lean and nimble. You won't know what your users really want until you get the product to them. The sooner you can do this the faster you can get feedback and create features real users are asking for.
No product will ever be perfect. It will continue to evolve and shape itself into something you may not even have expected.
Conclusion
I hope this post has helped you make better decisions with your software projects. If you have any questions about how you can avoid production problems feel free to write me, or catch me on LinkedIn
