3 Signs You Are Working With a Bad Dev Shop

dev_bad

Are you working with a bad dev shop?

Choosing a dev shop is challenging, especially when you don’t come from a technical background. It’s especially hard to choose a development shop if you have the wrong mindset. When you are building an app, think about how you would build a physical house, starting with a strong foundation first and then building out. The cliche of two developers working away in a room and coming up with the next Facebook rarely works.

Warning sign 1: Coding without a plan

Contrary to popular belief, the worst way to start a software development project is to start by developing the software. Much like you wouldn’t start building a random bedroom in a house and say to yourself, “I’ll worry about the rest as we get to it.” you don’t want to start writing actual code until you have both a clear understanding of the visual look and feel of your app, and also a game plan for the architecture of the app.

You must lead with a concrete vision for your app. You cannot iterate your way to success without knowing the target. Staying ‘lean’ and not planning isn’t savvy or cutting edge. It’s lazy and it’s done to avoid confronting the risks associated with the project in order to protect egos. Jumping into coding right away also leads to cost overrun as you never know the cost upfront, or at least you never feel like you were given a price. Even when you try to do both parallel it leads to disaster. There must be a clear-cut design and discovery phase, and then development can start. Yes, the software requirements will evolve, but that is not a reason to never set the requirements at all.

Warning Sign 2: Mismanagement of invention risk or market risk

There are two major types of risk with a new software project. First, there is invention risk. Invention risk is the risk of attempting to do something that has never been done, or risk that what is being attempted isn’t allowed due to legal limitations such as website terms of service or legal compliance. The second type of risk is market risk. This type of risk is related to releasing software that doesn’t end up having any user adoption.

Invention risk must be prioritized. Say for example you want to create an app that alerts you whenever a new show hits Netflix. The first priority should be on determining if Netflix has a datasource (often referred to as an API) that would provide you this data openly and economically. The wrong approach is to focus on how users will log in to your App, or if users should be alerted once per show or once per day. If you can’t get the data from Netflix, it doesn’t matter! Yet time and time again I encounter projects that are focused on fixing ‘bugs’ or worrying about how they will handle millions of users when their core idea doesn’t work.
Bad dev shops do this so they can take lots of your money working on the easy parts of a project, and then convince you to continue with the hard parts of the project because you have sunken costs. As a bonus the hard parts of the project never get done because any firm that ignores invention risk usually doesn’t have the talent to deliver projects that actually work.

It’s debatable whether a development shop can help with market risk. Many shops try and take a collaborative approach to working with clients, but ultimately you can’t outsource this type of risk. According to experts like Peter Thiel and Keith Rabbois your vision and will are the clearest indicators. This risk is usually an inherent risk with any new venture and is mitigated with a definite vision of what you are after, and a way to incorporate user feedback into your process.

Warning Sign 3: Minimizing the importance of technology

The old software adage, ‘If it works, it works!’ is false. Software is never done until it’s no longer used. Software is developed by people, and those people have not only skills, but also careers and ambitions. If your development shop uses a proprietary or exotic technology that it is a risk because eventually you may want to hire new people, either internally or externally. You’ll have trouble hiring if the technology is not widely used. A primary reason that may not be obvious to non-developers is that developers have incredibly short careers if they aren’t continuously learning. The technologies that are considered desirable are constantly changing, and undergo big shifts every 2–4 years.

A good development partner will advise you on the technologies that are being used and explain the trade-offs. In 2019 React.js is a popular technology used for websites and apps. If your development shop is advising Angular or jQuery that itself isn’t a bad sign. They might be the right technologies for the job, but they are riskier choices because they are not as popular in the development communities as React and as a result it will be harder to hire talent in the future to take over your project. It absolutely matters which technology is used and anyone that denies this should be avoided.

Did I just contradict myself by saying that you should be wary of exotic technologies, but then say to attract the best developers you need to use the latest and greatest technologies? Yes, but it’s because it depends on the prospective you are taking and the goals of the project. The unrelenting pace of innovation in the software development space means that the best technology for the job will vary year to year and sometimes even recycle. A good development partner can explain the changes happening, and make predictions and adjust based on the type of developer you want to attract in the future and your risk tolerance. It’s important to be wary of any extremists, these types of firms see themselves as having a golden hammer and every problem being a nail and likely are motivated more by building ‘cool’ apps than actually delivering your idea to market.

Do your homework when choosing a dev shop

Choosing a development partner is difficult because software development itself is complex. It is easy to find yourself in a situation that spins out of control because it is natural to want to believe whatever simplistic advice your development partner provides. It can also be difficult to accept that unlike a house, software is never done. The launch is just the beginning of the work. It’s essential to do your research before committing to development shop. Make sure that you’re working with a shop that is aware of the risks, is on top of new technologies, and values planning. A great development firm will view themselves as your partner on the road to success.

Share on facebook
Facebook
Share on twitter
Twitter
Share on linkedin
LinkedIn
Share on email
Email

Reader Interactions

Leave a Reply

Your email address will not be published. Required fields are marked *