SitePen is a web development company focused on modernizing apps, tools, and teams for the Enterprise. Our claim to fame is our long-standing development team that through the years has created, developed, and supported the longest-lived enterprise platform for client-side web development, the Dojo Toolkit. Today, our platform-agnostic approach to web development enables our customers to make intelligent choices that propel their company’s web initiatives forward, allowing for unsurpassed performance, modularity, and stability.
So let’s get right to it. Most established companies now have a web application and an internal web development group supporting their web apps and dev ops. So why do companies need outside development resources anyway?
The following is a transcription of the video shown above.
Why use an external development team?
Competing Priorities
Generally, companies with web operations have similar competing priorities, which most likely include:
- new development
- new features
- enhancements to existing features or entire new applications
- maintenance and support of existing applications
- testing and production
Each of these areas requires dedicated resources to execute on the company’s objectives.
Talent Scarcity
In addition to fulfilling the company’s business objectives, there is the inability to hire and retain skilled developers to fill out teams and acquire the specialized skill and experience to build out stable architecture and development operations.
Employment Costs v. Contracts
The cost of hiring and retaining skilled employees isn’t an apples to apples comparison to using outsourced development resources. The associated costs of recruiting, onboarding, benefits, paid time off, management, and retention of full time employees can easily exceed the cost of a contractor with equal skill and experience. Some companies value contracted engineering resources for this reason alone.
New Business Objectives
The company might have new business objectives that require a brand new application or functionality, but have insufficient bandwidth to develop something new and maintain the current applications.
Project Course Corrections
A troublesome project might require a course correction. These corrections are often best performed by an external party that can remain objective and focused on the project’s goals.
Team Burnout
Development teams can become overworked and run the risk of burning out. At some point, companies learn that the cost of attrition outweighs the cost of temporary external resources.
Where Do You Start?
So let’s assume that you fall into one of the previously mentioned categories. Where do you start? Technology and business decision makers are inundated with endless repetitive requests, offering expert, reliable, fast, quality, inexpensive, full stack, development services. Many pitches offer the world for a dollar, and others offer options such as no risk trials with access to hundreds of developers who can start today! If it’s too good to be true… So in a world with hundreds of potential development partners, what can you do to make sure that your expectations are met and that you deliver to meet your company’s goals?
Referrals
First, start by getting a referral. Talk to people that you trust and respect. Ask everyone you know before you go it alone.
Google Search
If your colleagues don’t come through for you though, you need to resort to, yeah, Google. If that’s the case, here’s where we can tell you what to look for, what to expect, and what you should get from any web development partner. Heads up. You can apply this info to referrals as well.
Shorten Your List of Contenders
So before dropping a line, you’re going to need to shorten your list of contenders. Let’s go through a quick list that will help you narrow the field.
Does the company claim to be good at everything or are they exceptional at a smaller range of technologies?
Generally, experts are one to two orders of magnitude more efficient in their area of expertise and far more likely to create high quality, easy to maintain source code. If they list every technology, platform, and tool under the sun, you can cross them out.
What is your first impression of their website? Does it have a hideous design and glaring grammatical errors?
Software engineering is a mixture of science, art, and attention to detail. To create code that is easy to test and maintain, all of the small details matter – ranging from seemingly pedantic details such as usage of whitespace and approach to variable names, all the way to page load times and returned 404 errors. When you make sure all of the details are consistent, it leads to results that are higher in quality, work as expected, and easier to fix when something does go wrong. In this regard, it’s a safe bet that you’ll see the same problems with your app as you see on their site. Poor design, spelling errors, poor performance, etc..
Are they experienced? Do they have a portfolio? Testimonials? Active GitHub and social media accounts?
It is common in our society to fall in love with the idea of the 12-year-old who starts a software company. But that’s the exception rather than the rule. Building well crafted software takes years of experience and typically five to ten years of dedication to master. Yes, it is possible to be productive sooner, and it’s also easy to find engineers with more experience that have not mastered their approach. But experience is hugely beneficial for complex software projects. If you can’t find this information, scratch.
Are they good problem solvers?
When an engineer lacks the understanding of the platform, they will struggle to solve new problems. A typical engineer may spend as much as 80% of their time trying to understand why something is not working the way they expect it to. A strong problem solver can shrink that ratio and greatly increase their productivity and find solutions more expediently. This is difficult to determine in advance of working with an engineer, however. You may be able to ask specific questions or search out a white paper they’ve written to see what types of challenges they’ve overcome.
Is your development partner someone that uses the platform, or do they help create things that make it better?
Firms that create portions of the platform have a deeper understanding of how things work and are much better at finding solutions to your problems. Even if that problem is tangential to the technology you are using. Hiring community contributors is better for your team, your company, and the open source community. If they don’t have a meaningful GitHub presence to technologies relevant to your stack, cross them out.
So far, we’ve eliminated contenders that:
- claim to be jacks of all trades
- have a poor Web presence
- appear to be lacking experience or a valid portfolio
- are not contributors to relevant open source communities.
Time to Pick Up the Phone
Now, let’s get into the meatier areas of what you need to evaluate when choosing a web development partner. Hopefully the potential partner candidate has demonstrated via their website, portfolio, and testimonials that they have the technical skills to complete your project. And even with this as our premise, we recognize that proper evaluation can only happen during an engagement. However, we have some important information that can potentially help you in your decision making process and reduce the probability of choosing a bad apple.
1. Do they have the ability to translate requirements?
In a world with increasing demands for software and business agility, it helps to have a partner that can understand business requirements and efficiently translate them into technical requirements. It is painfully expensive to create the wrong feature or to not create something that meets the needs of the business. Even in an agile environment with regular flux, it helps to take time to understand what needs to be built before you start creating source code that will need to be maintained and extended.
So start by asking the questions:
- What is your process for determining scope?
- What is your process for understanding scope?
- What is your process for validating scope?
- What is your process for tracking scope?
An experienced development partner will skillfully walk down each of these four sections and be able to explain to you their preferred workflow in each in a clear, concise way.
TIP: listen for words like ‘ongoing’, ‘revisit’, ‘clarification’, and ‘documented’.
2. Are they transparent?
A solid development partner will employ a process with maximum transparency. This will translate to regular and ongoing access to the source code being engineered, the team working on the source code, and the status and issues of the current project. Software development can be a messy process. While some firms are reluctant to provide visibility into their process, without this transparency, you will literally be in the dark about the quality of the engineering effort and will be unable to provide open, ongoing feedback throughout the project.
So what questions can you ask?
- How often will I receive updates on development progress?
- How often does your team upload their code?
- Will I have ongoing access to the source code being deployed?
3. Are they predictable?
A development firm tells you that they can finish the project by your target date at half your budget. No problem! If it seems too good to be true…it definitely is.
So ask the question: What’s their process if something happens on their side that causes the timeline to slip?
TIP: Listen for words like ‘fixed bid’, ‘change order’, and ‘as much notice as possible’.
4. What is their process?
A quality development partner will always communicate their approach, plan, and deliverables in a schedule that is maintained and updated frequently, thus providing you with a valuable, intangible: Predictability. By communicating the plan up front, you will get a set of realistic estimations that target your timeline and budget. Of course, these predictions will need to be adjusted on an ongoing basis to accommodate changing business needs. However, communicating the effects on timeline and budget in real time as those needs arise, make it easier for you to manage your resources and internal expectations accordingly and with confidence.
So ask the question: How do you maintain the milestone schedule?
TIP: Listen for key words in their explanation such as ‘review’, ‘adjust’, ‘mutually agree’, ‘update’, and ‘document’, which allude to keeping you apprised of status on an ongoing basis.
5. Are they consistent?
Even for projects where predictability may be challenging due to various moving parts, setting expectations that there will be consistent discussion, standard reoccurring updates, and regular deliverables is the best alternative to predictability. For instance, if you know that every Tuesday there’s a review of requirements and clarification session, and that every Friday you will get a full status update and source code drop, and every three weeks you will receive a set of deliverables and release notes, you know how to start planning for review, QA, next phases, and production.
So ask the question: When can I expect to hear from you?
They should be able to quickly suggest a desired schedule as an example, which they use as a standard schedule with their customers for calls, code drops, and status updates.
TIP: If they say ‘whenever you need us’, be wary.
6. Communication
If you do not know the current status of your project at all times or what to reasonably expect, then there is a serious communication issue. A partner with strong communication skills will make sure you fully understand the status, will manage meetings efficiently, and will also understand when to spend extra time to explain something, and when to give you the condensed version. Teams with strong communication skills should not just be good at verbal communication, but must be excellent at the written word. Taking time to document their approach, making their work easier to understand and maintain.
7. Collaboration
A valuable development partner improves your team by listening to requirements and challenges, sharing knowledge, and determining solutions through collaboration throughout the life of your project.
8. Adaptability and Leadership
A strong, experienced development partner will approach every encounter with a sense of purpose that fits within a process. They will have flexibility to use their own process or adapt to yours based on your preference, but with the know-how to fill any gaps that affects the productivity and success of the project. They will be able to identify the project lead who will align and deliver on the objectives of both companies.
TIP: Be wary of phrases such as ‘whatever you say’, ‘just let us know’, and ‘we’ll wait to hear from you’.
9. Documentation
Documentation, documentation, documentation, every meeting, discussion, decision, clarification, question, answer, anything spoken, should be summarized and documented for the benefit of both teams. It is essential that all key decisions and approaches are documented concisely over the course of a project. Disciplined development partners are masters of written communication and documentation.
10. Testing & Quality
Finally, you’re going to need to get a pretty good answer to this:
- What is your approach to quality assurance?
You should be able to get an answer that includes the following information:
- What is their testing strategy?
- What are the code coverage targets?
- Do they conduct internal reviews?
- Do they build into the schedule a time for you as the customer to do testing?
- How do they resolve bugs and issues?
- How do they ensure that they provide clean deliverables?
It is impossible to know that an application works as intended without a strong collection of automated test cases. Tests should also be authored as applications are created rather than being deferred until the end of the project, if at all. Solid code coverage is essential to know that all things have been tested. It is far less costly to address issues of quality during development than it is once an application has been deployed to production. Ongoing automated tests help catch regressions as well as changes to the platform that may impact your application. Test authoring should primarily be done by engineers, so tests can be created as part of the ongoing development process. Source code that is not tested, should not pass a code review and should never make it into the master source code branch.
What do you value?
So we’ve outlined 10 things to discuss with a potential development partner. Now it’s time to weigh those things against what you value as a development manager. Here it comes, the age old question: What do you value?
Cost, quality, speed?
You need to identify what your priorities are to determine what you’re looking for in a development partner. If cost is prioritized over quality and speed, you may need to lower your expectations on timelines, documentation, and code coverage to be in line with reducing costs.
Organization and Process?
Do you run a tight ship? If you’ve got a great organization, documentation, dev ops and requirements, you’ll need a highly adaptable partner to fit in with your workflow. But if you’re the opposite, you’ll probably need more leadership skills from your partner.
Flexibility and Agility?
If your project team runs with ever changing goalposts, slow decision making, and team burnout, having a partner with great communication, follow through, and attention to process is going to be a value add when trying to keep productivity high in development while supporting business objectives.
Decision Time
So now, armed with all of the information that you need, it’s time to make a decision. So let’s go over the list one more time.
- Do they have the ability to explain their process for translating requirements?
- Will they be transparent throughout the development lifecycle?
- Do they have a plan for predictability?
- Will their process support your success?
- Will they be consistent?
- Will they be communicative?
- Will they be collaborative?
- Are they leaders?
- Will there be solid documentation provided throughout the project?
- Is there a focus on testing and quality?
When all is said and done, trust yourself
What does your gut say? After speaking to various development partners, you ultimately have to go with your gut.
- Did they put you at ease?
- Were they objective and non defensive?
- Did they provide answers that met your expectations?
- Do they instill confidence that they had an approach that would deliver results?
Often your intuition following a few discussions will guide you to your final decision.
Conclusion
It is our intent to push the limits of the open web through the development of even better enterprise tools with our contributions to the TypeScript language – the smart way to write clean JavaScript, development of Dojo Framework – the next leading framework in enterprise web development, and Intern – our automated testing tool, all with a focus on giving developers the right approach to helping their companies succeed.
If you have any questions or want to learn more, please feel free to reach out and get in touch with us. For now, I want to thank you for your time and wish you luck as you either begin or continue your process of selecting your next development partner.