“Your app will be finished on Tuesday.” — which Tuesday?!
If you search online for trends in software development you’ll find an endless supply of information on booming technologies and how tech is going to impact every sector by 2020. We hear about all the amazing changes new technology will have ad nauseam, but I’m here to question the latter part of the previous sentence.
“By 2020”. For those of you who don’t speak “software engineer”, that means 2040.
As the only guy at Crane.ai that doesn’t write code, I’ve been plagued by this problem for the longest time. Of course, non-coders are also part of the problem; this post was originally going to be about 5 reasons why software development projects fail, but in full client fashion I changed the spec halfway through the project and so it’ll now be about 10 reasons why software development projects fail.
“Mobile app? We built a bridge, does that work?”
One of the largest problems plaguing software development projects is a poorly defined outcome. Without proper definition as to what the “end product” should be, a project is guaranteed to fail.
This is so vital that it could quite possibly change the direction of the project itself (which is why it’s #1 on my list!). I highly recommend building a specification sheet to better identify what the product will look like, what it will do, and how it will do it. More on this under communication and expectations!
“We built a new wooden bridge that looks way prettier than the old one. Cars? Oh, no, it can’t support cars. Pretty much anything heavier than a bird will break it.”
Another common issue is solving the wrong problem. This lies along the same lines as a poorly defined outcome, yet is much broader in scope. Although you can properly identify your end product and solve the other issues discussed here, if your solution does not properly address the problem then you’ve gotten nowhere with the project.
One way to solve this is to incrementally ideate. Identify your core problem, what steps could be taken to solve it, and a possible solution. Next, constantly iterate the product through with your end user — maintain a constant review process to ensure the project is properly addressing the needs of your user, and remains a solution to your core problem.
“We built half a bridge, they built half a tunnel.”
Coming in at #3 is the core problem plaguing virtually every project, industry, and business — communication. Communication is vital at every level of a software development project.
At an internal level, your developers need to communicate effectively to ensure they build tools and pipelines that in coordination and are properly compatible. A common solution here is to draft specifications beforehand for design, APIs, and any other engineering required in your project. This is vital to saving hundreds of hours of time that could otherwise be wasted in refactoring and restructuring.
At a higher level, it’s also important to properly communicate with other teams. The marketing team, for example, needs to know what is technologically feasible before selling the concept.
Failure to communicate at this level can cause project-shattering issues; the product could end up being severely detached from what was sold, promised, built and needed.
“Yeah… it’ll get done around like… maybe a couple weeks? Not sure what we’re gonna do after that…”
Regardless of whether timelines and plans are adhered to, it’s important to have one. It provides your project with a sense of structure and gives you an estimate as to when and how tasks will be completed.
Of course, a good plan reaches much further. A good plan or timeline can also serve as a common border for large teams, allowing them to operate quickly and efficiently in sprints. If a feature falls through or needs more time, then the plan/timeline can be adjusted quickly, and the budget adjusted accordingly.
“The buck stops… over there, bye!” — Harry Truman, probably
When shit hits the fan, someone has to be ready with a mop. If a feature falls through, it should be clear who is accountable and what steps should be taken to prevent this in the future.
It sounds childish but a common occurrence in the software development industry is “pointing fingers.” The backend engineers will blame the frontend engineers will blame the sales team will blame the marketing team will blame thelegal office will blame the management will blame… This process is not only time consuming and disastrous for morale, but it leaves the core question — “what went wrong?” — open and unanswered.
“Ok, but now the bridge needs to also act as a runway, have 10 more lanes, and how about a park in the middle of it?”
It’s important to keep track of a project’s goals and make sure they are met in a timely fashion. While it is possible that a project needs to be expanded or the requirements have changed, making frequent modifications to the “end goal” can not only devastate morale, but make a project outright impossible. Often times, changes are unplanned and require extensive refactoring; over time, this leads to a large amount of wasted time, and eventually a failed project.
What may seem like a small change at first could end up becoming a long-term development project.
“The instructions to defuse this bomb say to pull the red wire once the power cuts off, but all of the wires are red and the power was supposed to be cut 10 minutes ago!” — James Bond, at what will be the end of his career
It’s great to follow an agile methodology and move fast, but documentation is always important. Undocumented code can lead to years of technical debt and can cause tremendous issues down the road — “what does this function do?”
It’s equally important to document the product. Every step of the process from ideation to design to execution should be well-documented to ensure that the project is easily navigable for others and stays on track. Good documentation can allow for easier project tracking — in an agile system, try a kanban board or similar to keep track of tasks!
“WTF do you mean there’s only 5 loaves and 2 fish for all 5000 of us?!”
The technical requirements of a project can be hard to gauge, but it is extremely vital that you do so. What may seem like a small extra addition may turn into a turducken of an issue, involving allocating additional infrastructure and redefining the entire system to introduce support.
“We’re still flying half a ship.”
Often times a project is exciting and easy to jump into; however, it is vital to its success for the proper preparation to take place. Specifications need to be created, designs must be drafted, a timeline should be agreed on, and resources should be allocated.
A popular method of managing this at a technical level is Test Driven Development. Before writing a single line of code towards a project, plan out the architecture and what each piece needs to accomplish. Next, write tests to assert that each piece actually does what was intended. In this manner, you have a framework ready with set goals and can quantify progress on the development of your product.
“Ok, the app looks good — but why doesn’t the color scheme automatically change to match the user’s phone case?”
It’s important to manage expectations. Often times, the client asks for a feature that is unreasonable, impractical, or flat-out impossible. A common practice is to limit the number of changes that can be made to a spec and to have an engineer present during discussions to determine if the proposed feature is technologically feasible.
Hopefully, by avoiding these 10 pitfalls, your next software development project will be an astounding success! What issues have you run into in your software projects?
Hey! I’m Tomer, an entrepreneur, and maker. You might know me from Mevee, Crane, Shots, Slides and now investorintelligence.io among other products I’ve launched! This article is a part of a more extensive series I’m writing mostly based on my experiences and is mainly made of me and my team’s opinions.
I hope this helps you to avoid making the same mistakes I did, and remember to keep shipping!
Please clap 👏 if you found this valuable, and follow me 👈 for more writing like this as I share stories about what software development and entrepreneurship looks like in real life.
“Your app will be finished on Tuesday.” — which Tuesday?!
Research & References of “Your app will be finished on Tuesday.” — which Tuesday?!|A&C Accounting And Tax Services
Source
0 Comments