When to Hire App Builders
Or better yet… when NOT to.
Software app programmers, architects, engineers, developers… front-end, back-end, full-stack or whatever you wanna call them. I’ve managed software builders for the better part of two decades.
I’ve hired brand-new developers still in high school, I’ve hired self-taught intermediary developers and I’ve hired senior software engineers with advanced computer science degrees. They range in capabilities, from fast starters to strong finishers, and most have been super smart. But I can tell you one thing… 95% of software builders are NOT planners. Truth is… they love to CODE, can’t wait to code… they live to code… by day and by night, they code.
Now, I know most software shops have planners called “business analysts” and “project managers” but these companies are built on the backs of their programmers. No doubt, although planners are the ones responsible for delivering the outcome, the builders fight hard against letting the “tail wag the dog.”
The argument goes like this:
- “You aren’t being AGILE” unless you start banging out release #1 and iterate from there.
- Without programmers involved right away, “you’ll plan for functionality that isn’t practical.”
Indeed, P-L-A-N, is a four-letter word most commonly saved for team retrospectives. In other words, time-after-time like a broken record — once the project is over, the teams agrees “we shoulda planned a few things better.”
Here are the facts:
- Agile requires understanding your minimum goals.
- It’s critical to know all the functionality you want- even if we later figure out a better way to achieve it.
- Coding too soon means EARLY “technical debt.” Technical debt requires the support of specialized knowledge.
It’s just common sense…. NO software language is EASIER to change than words/ drawings on a page. Ya see, once coding starts– the only people who can make changes are your programmers and if you failed to put in solid planning: you’ll need a TON of changes. Think about it like this — every hour they spend changing something you coulda deleted from a schematic in 5 minutes, drives your project costs sky-high. Hey, that’s great job security for the programmer but it’s bad for your budget.
BOTTOM LINE: If you wanna build a house, you hire the carpenter to frame the structure AFTER you’ve made decisions about what that structure should be. Good planning vastly reduces project costs.
Importantly, your planning efforts need to be handled by someone who’s:
- Expert in technology and the software development process. This means low risk for planning functionality that isn’t practical and an understanding of how to meet your goals. In addition, experts in software development have an astute awareness of how best to employ Agile methodologies.
- Unbiased with regard to your project size.
- Affordable because the point of planning is for efficiencies that reduce your costs. Planning is critical but avoid paralysis by analysis.
- Focused on your needs and goals when creating and overseeing the project.
Hire your initial planning team separate from development.
That’s right. Think about it… the last thing you need is smart people behind a complicated technical veil who’re paid based on how big your project can be. Instead, hire a team to analyze and help you plan your project separately from the team who’ll BUILD. This team should be far more efficient and will objectively hear what you want without a tendency to inflate the project’s size. In fact, if that team is experienced, they’ll be good at honing in on your minimum needs so you can use LEAN principles to iterate based on actual usage and user feedback. And this team will not only be adept at communicating what needs to be done to the developers you hire — but they’ll be your advocate if developers start heading the wrong direction or pushing to needlessly expand scope.
That’s what Devtree does. We make it very clear WHAT to build… and then we get qualified software builders to bid on your job.
Importantly, this approach allows:
- Development to be very Agile because minimum needs are identified and iteration can be prioritized.
- Programmers ARE involved early (coding hasn’t started yet!) — so their feedback, with full scope in mind, is even more helpful. Better yet, astute shops provide this feedback along with their quote — which you’ll find valuable in selecting your software building team.
The adage still applies…
Measure twice. Cut once.