Selecting Tools
You have your plan, you have your team, you have your clients, and you're about to start development. The only thing missing is the tools you'll be using. This is one of the most crucial single moments in the development cycle.
The collaboration tools, libraries, frameworks, architecture, deployment environment, ... that you choose at the beginning of your development cycle will have an enormous impact on the future health of your product. And not necessarily in the ways you'd expect.
It all boils down to one main consideration:
Technical Debt Given your set of resources, will a particular choice of tools increase or decrease your technical debt over time?
Index
Technical Debt
There is a lot of pressure to use neat and powerful tools. This may be an ideal choice in an ideal world, but the decision must be driven by an honest assessment of your available resources.
Know Your Resources
More often than not, your 4 most limiting resources will be human capital, time, money, and clear specifications.
Avoid The Hype
Some Consideration
The ultimate question is this:
will x time-saving tool save more time than it takes to learn? and will it save more time than it takes to make up for rookie mistakes?
Let's look at this in more specific terms.
- Clear specifications. Let's get this one out of the way first. It will be an underlying consideration in all of the remaining analyses. Whether you're a pm, a developer, or anything in between, your ultimate job description is to build software that meets the customer's needs. Customers are notoriously bad at knowing what they need. Marketers are notoriously good at convincing customers they need something. You can see where this is going.
- What is your team already familiar with? Using a tool your team is not familiar will tap into all of the important resources - extra time to train, extra money to pay for that training time, and even more time and even more money when you need to refactor or bug-fix because of your team's inexperience with certain libraries or frameworks.
- What's the most effective use of your team? The end goal is to deliver a reliable and meaningful service to your client within schedule and within budget that can be maintained, modified, or scaled to meet their needs. Nowhere in that definition does it say you have to write the software yourself software. Your team, your time and your money might be better spent setting or white labeling up a third-party saas, testing it for all use cases, and integrating the necessary plugins or api's. This might deliver a better product, faster, and under budget.
Resources
Technical Debt:
- Avoiding it
- It's just bad technical upgrade
- Adaptable Design
- Not all debt is bad: 3 types
- Think "Lego Blocks"
- A bigger picture
Assorted:
