May 27, 2020

Making Javascript a bit sweeter: Yarn berry(v2) and its usefulness.

How'd we get here?

In the 2019 not-so-official state of Javascript report, I heard the undertones of anguish and grumbling towards the javascript ecosystem, but whats new right? People have been complaining about Javascript since its three week incubation and subsequent birth. For good reason.

Example, executing random type additions:

> "" + {}
> "[object Object]"
> {} + ""
> 0

But…somehow, through all the pain and chaos, we have come together as a community and have made this language somewhat bearable to work with.

In 2012, Typescript was born and all of a sudden you could add Types!.to!.Javascript! as ForSortaRealNow.

In 2015 there were whispers of something called the webpack and react and all you had to was provide a small sacrificial offering, followed by installing the universe of npm modules to use them. Only then, would you be on your merry way.

In 2016, 2017, 2018, and 2019 if you updated a package and something broke, there was usually at least one GitHub issue that would say something nonchalantly like “Breaking change, no take backs”, and then go on to explain why you would be spending the next three days upgrading all your dependencies and refactoring your whole application. By the way, if this was you, I personally want to say “You’re a hero”.

Jokes aside, 2015-present has really been a journey of intense growing pain, but I personally believe we are on the brink of a new era of Javasc–cough Typescript. Yarn V2 just came out, and I am seriously more pumped about the ecosystem than ever. I would put this change on the same level of importance as the move to ECMAScript 6. Yep I said it. Let me explain why.

Yarn V2


Workspaces were a concept in V1 of Yarn, they should be thought of like a module. You .NET devs can think of them like a project within a solution. They are a good solution for a monorepo, but in V1, a lot was left up to the developer to get all their dev tools (Typescript, Webpack, and VS Code, etc) all on the same page as to what was going on with those workspaces. I remember it took a week or two for me to just get file resolution sorted out between all of that, and I know for fact, that setup was custom…and not quite right. 🙂

After you have gone through the migration to yarn berry, you can set up a more realistic and safe monorepo without worrying (too much) about how those workspaces are going to get resolved. Workspace resolution is treated as a class one citizen now. It even has its own protocol.

Assume the following directory structure

 - packages
     - web
         - src
             - data
             - components
     - api
     - shared

To reference another workspace from the web workspace, use the workspace protocol . Example:


"@repo/shared": "workspace:packages/shared"

example use:

import SomeSharedThing from "@repo/shared/SomeSharedThing"

Okay, but why was this a problem in V1 and why does it work better now?

Plug’n’Play, Plugins, and File/Module Resolution

The Problem: Resolvers.

Here is an excerpt from the yarn docs linked above that explains it well:

“Over the years that led to Plug’n’Play being designed and adopted as the main install strategy, various projects came up with their own implementation of the Node Resolution Algorithm - usually to circumvent shortcomings of the require.resolve API. Such projects can be Webpack (enhanced-resolve), Babel (resolve), Jest (jest-resolve), Metro (metro-resolver), …”

This means that if you wanted to combine and use different technologies that use different file/module resolving strategies, you would likely be dealing with configurations to make sure files are being resolved correctly.

But no more. No more tweaking aliases in configs. No more help from random third party resolvers, etc. No more.

The Solution: Plug,'n’Play(pnp.js)

Yarn V2 solves the file resolution issue through the use of the pnp.js file and their plugin strategy.

  • They introduced the concept of the pnp.js file (If you have ever used webpack stats, it is similar to that). Basically it’s a file that declares explicitly what dependencies/workspaces depend on and where those packages are all the way down the dependency tree. It then during runtime(think webpacking) can intercept calls to modules, and provide a virtual link to where yarn is keeping those modules now which by default are zipped within its cache folder. For developer tools like eslint, typescript and vs-code they wrote a pnpify module that basically fakes the existence of the node_modules folder for the same purpose. This is temporary until those tools can support pnp out of the box.
  • Yarn V2 is built primarily using a plugin strategy. Things like commands are even plugins(e.g yarn add). Along with commands, they have also built plugins to wrap how files get resolved from different mainstream file resolvers.

Together with the pnp.js file, and plugins, they can look to see what module resolution a package depends on (via the dependency tree) and then tell Node exactly where to find that module/package.

Zero Installs

Yarn berry has some great documentation around this topic. Zero installs is not a feature specific to yarn berry, but it is by far more possible because of it. Since, node_modules are no longer a thing, and instead the yarn cache is maintained through compressed .zip files, It is much more feasible to commit these to your repository. Zero installs is configured purely through .gitignore. You can choose to do so or not. Read more about it here.

I have decided to jump aboard, and have not regretted it one bit. It improves workflow all over the place, specifically around switching branches during the PR process and the build process itself.


Yarn 2 has the option to provide constraints. Constraints are rules about your dependencies. Yarn has defined a few of their own constraints, but you can also create your own.

The yarn maintainers are using a programming language called Prolog to create these constraints. Prolog is a fact based engine. Think of it as a database of facts that we can query against and determine if something is true or not.

From what I understand…upon running yarn constraints yarn berry generates a database of facts using the projects workspaces, and dependencyTypes(dependencies, devDependencies, etc) and in plain english those sound something like

“fact: the workspace someWorkspaceName depends on Lodash version 4.4.2 in devDependencies” -yarn docs.

Then it gobbles that list of DB facts, the predefined rules yarn has provided, and the source file the end user provides for custom constraints( by default). After that it loops over a list of query results provided by tauProlog’s(JS wrapper around prolog) query method and generates an array of enforced Dependencies.

Now constraints like Uncle Bobs dependency rule are much more possible and more importantly, enforceable.

This rule says that: “source code dependencies can only point inwards. Nothing in an inner circle can know anything at all about something in an outer circle. In particular, the name of something declared in an outer circle must not be mentioned by the code in the an inner circle. That includes, functions, classes. variables, or any other named software entity.” - Uncle Bob

Constraints are still in newborn status, but I plan on using them.

To wrap up. I have a lot of hope for Yarn v2. The lead maintainer @arcanis is someone I have come to respect, and is someone who not only sees the issues of the JS ecosystem, but has solved those problems. IMO, Yarn V2 is the future of the JS/TS ecosystem. At least until Deno takes over.

March 27, 2020

Leadership in the time of COVID-19

I think it’s reasonably safe to say that when I first started at DeveloperTown in 2014 I was not expecting the following two things to become a reality: that I’d last in a software development consulting firm with no software development knowledge and that I’d eventually write a blog post about leadership in the midst of a global pandemic.

Both are true at the moment. I’ve come quite a ways from being clueless about what an API was or in the dark about things such as pull requests. (Quite naturally, as a 16 year old boy stuck in a now 33 year old’s body, I assumed a PR had to do with a rather gaseous bodily function and my index finger.)

But here we are. Slightly more knowledgeable about software and spending most of my time indoors as our brave medical men and women, delivery drivers, teachers, grocery store clerks, and city employees are on the front lines. It’s a scary time. A time where I often wonder what should we be doing? Who is going to stand up and lead? How should they be doing it? And what about us that are not guaranteed a future? What about our jobs? How are we going to make it?

These questions are undoubtedly floating through your head and the head of your bosses, coworkers, and employees.

And if you find yourself in a place of leadership, now is the time to answer those questions.

One of the many reasons I’ve stuck around at DeveloperTown is the fact that we have strong leaders. Leaders who are trying to answer those questions. Leaders who I trust will do the right thing, not only for the business but for their employees as well.

But what does the right thing look like now? I have a few suggestions that come straight from the DT leadership playbook.

  1. As a leader, it’s more important than ever to communicate with honesty and empathy. People are going to create their own narratives if they don’t hear one from you. They may even create one if you share the truth over and over. But they deserve to know where the business stands and where you see it going. If you don’t know, that's okay too. Tell them what you do know. No sugar coating, no false hope, no unneeded dread.
  2. The best way to reduce anxiety is to start thinking about what your organization can do for others. How are your clients feeling at this time? Serve them with grace and care. Demonstrate this to your team. Vocalize it over and over. There’s never been a better time to revisit your mission statement and remind yourself and your team that now is the time to serve others. It’s really hard to worry about yourself while you’re helping someone else.
  3. Samuel Johnson was quoted as saying, “People need to be reminded more than they need to be instructed.” I happen to agree with him. Set up recurring touchpoints with your team to celebrate their wins and check in. Be available. A great example of this would be a now weekly virtual coffee social via Google Hangouts at DeveloperTown. An employee put it together and it’s been a highlight of this time in quarantine. It’s a weekly reminder that we’re in this together...and that some of us have very fun coffee mugs.

Leadership in the time of COVID-19 doesn’t have to mean a monumental, solo effort for only those at the top. But for those who find themselves in or identify with a leadership role, now is the time to communicate, serve others, and regularly remind our teams that we’re in this together.

When things get tough, it’s up to good people to stand up and do our part. Luckily, that means all of us get to help.

Even those of us who start blog posts with a fart joke.

March 17, 2020

Tech Talent: How to How to Beat Your Competition in Today’s Talent War

With the unemployment rate hovering below 4% nationally, companies all over are fighting to snag the best candidates on the market. To win the talent war, you've got to get creative on how you attract the talent your business needs to grow and succeed. But how can recruiters and talent management folk do just that? Well have no fear. We’re going to cover a few different tactics you need to be using to make the recruiting process as efficient and painless as possible.

First, let’s talk communication. This sounds like a no-brainer but thorough communication and follow through can be your competitive advantage against your fellow recruiting peers. I can’t tell you how many times a candidate tells me about a bad experience they’ve had with a recruiter, and usually it's always focused around poor communication. From first look to first day, it’s imperative to set expectations as to how and when communication will occur. Sometimes, even text check-ins are sufficient, but whatever you and your candidate agree to, don’t let them fall into the forbidden resume black hole. Even if you simply check in to say that you don’t have an update, that will go a lot further than radio silence. It’s important to have empathy for your candidate, as you certainly wouldn’t want to be forgotten about.

Next, let’s discuss candidate applications. Majority of candidates are applying to jobs from their mobile devices. Have you taken the time to test your company’s career page and apply to an open role via mobile? How long does the process take? Are there tons of questions/forms needing to be filled out? If the mobile application process takes over two minutes, it’s time for a change. Once you’ve simplified the mobile application process, look at the job description you or the hiring manager has written. Essentially, candidates want to know three main items: an overview of the company (culture), an idea as to how they’ll impact the business and the expertise needed for the role. Provide four to five bullets per section, no more is needed. Ideally, you are trying to cast a wider net, and if you have an abundance of “requirements” even some of the most qualified applicants may not feel they’re qualified for the role, thus won’t apply at all.

Last, be ready to battle the dreaded counteroffer. Companies know how hard it is to find talent, and subsequently they don’t want to lose that talent. Educate your candidates on why accepting a counteroffer is never a good idea. I read a few years ago a study which said 80-90% of candidates who accept a counter offer from their employer end up leaving within the following twelve months. Currently, I’ve found money is not the most pressing factor for candidates to want to leave their organization. Career growth/opportunity and feeling of purpose are on the top of the list. Remind your candidates as to their motivating factors for wanting to leave, and why you started the conversation with them in the first place. Being their sounding board builds trust in the recruiting process, and proves you are truly their advocate.

Winning the talent war doesn’t have to be a monumental task. With the right mindset and preparation, your organization can win the battle and set yourselves up for long term recruiting success.

February 3, 2020

Hiring Consultants 101: Hiring an Expert

Hiring an Expert

On our blog, we’ve talked about several aspects of what to look for when looking for delivery partners, and today we’re going to take some time to dig into what it means to “Hire an Expert”, and how to identify one. This is a critical skill that really needs to be sharpened if you’re going to be working with someone to facilitate and accelerate your projects. We’re going to look at why you should or shouldn’t hire an expert, and what makes an expert, well... an expert!

We Need Help (Resources)

You’ve decided that you need help with your project and that’s a huge step. The next phase is when it gets challenging. You have to find out WHO can help you. Do you need more resources to do more work or do you have bigger decisions to make? If you just need resources, you’re probably not looking for an expert. Don’t get me wrong, you may need very Sr-level resources with huge skill sets, but you’re looking for delivery and that means you’ll want to screen contractors or use a trusted partner to supply you with proven resources to get the job done.

We Need More Than Just More Resources (An Expert)

When more input is needed to your process than just solid delivery resources, you’re probably going to need an expert… at something. The What and When and Why of that decision is a topic for another post, right now we’re going to dive into what you’re looking for in an expert.

An Expert Is...

An expert is a thought leader, which means that they are well-equipped to engage in your process at levels broader than the nuts and bolts of delivery and can contribute meaningfully across a broad range of team activities. They also have three key characteristics that can make or break an effort:

  1. Experts can communicate with the team

    We specifically chose the word “communicate” instead of “talk” or “engage” because communication implies that the concepts that they are conveying are understood more or less intact by the team at all levels, so that aligning everyone happens naturally through the course of regular communication.

    Some teams are resistant to outside input, we’ve seen some pretty hairy conversations develop around hot project topics, but part of communication is wading into the mess and working to sort it out.

  2. Experts have opinions and rational, defensible reasons for them.

    An expert will present a cohesive vision for how delivery looks in their ideal world, be able to tell you why this is a good option for your business, and be able to answer the “Why” behind their vision.

    We’ve been in many situations in software development where someone has presented a path forward to me and given me options for two to three different implementation stacks, along with a nice list of pros and cons for each. That’s great, it really is, but doing research and pro/con lists for a tech stack is something we would expect one of our delivery people to be able to do.

  3. Experts will know (and tell you) when you don’t need them

    Sometimes the expertise doesn’t match the need or is at the wrong point in the process, or… whatever else. For some reason things just aren’t matched up right. An expert will come to you with these concerns and let you know when the fit isn’t right. In many cases they may even be able to recommend someone in their network who could be a better fit.

    This can be a hard pill to swallow on both sides, but it’s a matter of knowing where personal limits are and understanding that not everything can work out every time. When a mismatched relationship is forced, the stress eventually fractures the relationship, and oftentimes leaves the project in an uncertain state of success or failure. An expert will do everything they can to prevent that.

There are many, many more characteristics that make experts valuable, but the core value around it all is that they will all be dedicated to your success because they know that’s how they achieve success as well.

To Hire, or Not To Hire… That is the Question

Whether or not you need an expert is a highly situational and business-driven decision that will need careful consideration whenever it comes up. It’s important to make sure that when you do engage, that you maximize the value of your expert by taking advantage of their skills and outsider perspective and be open to the ideas they bring to the table. They are opinionated, but flexible, and can shed invaluable light on parts of your process or plan or implementation that we in the trenches are often too close to see clearly.

November 6, 2019

Android 10 UI KIT


Google has rolled out the newest update for Android. Android 10 update brings with it some big features including Live Caption, Smart Reply, Dark Mode and much more. The OS is available in general release now. We’ve created the Android 10 UI Kit to help designers crank out beautiful designs with the most up-to-date Android UI! UI Kits are now available for both SketchApp and Figma, and you can download them all below.


As with our last kit (Wear OS), we have vector screen designs created based on extensive research of the OS, including a ton of reusable symbols. This kit includes all of the main updates in the new OS, as well as some default app screens, and vector app icons. You’ve got everything you need to show off your awesome new app designs!


You'll need the latest version of Figma or SketchApp and Google's Android System fonts, Roboto and Roboto Condensed. You will also need Google’s Product Sans font (aka Google Sans), which we, unfortunately, cannot provide for you. You can find a copy of the font relatively easily online, or you can replace it with Avenir Next, which matches it very closely and is included in Mac OS.


Download the Android 10 UI Kit for Sketch here.

Or for Figma, just go here:


Check out DeveloperTown's handcrafted Material Design 2 Kit and Apple TV UI Kit. You can also follow us on Dribbble!

November 6, 2019

SAP Fiori Design System for Figma

SAP FIORI Design System for Figma

Google has rolled out the newest update for Android. Android 10 update brings with it some big features including Live Caption, Smart Reply, Dark Mode and much more. The OS is available in general release now. We’ve created the Android 10 UI Kit to help designers crank out beautiful designs with the most up-to-date Android UI! UI Kits are now available for both SketchApp and Figma, and you can download them all below.


As with our last kit (Wear OS), we have vector screen designs created based on extensive research of the OS, including a ton of reusable symbols. This kit includes all of the main updates in the new OS, as well as some default app screens, and vector app icons. You’ve got everything you need to show off your awesome new app designs!


You'll need the latest version of Figma or SketchApp and Google's Android System fonts, Roboto and Roboto Condensed. You will also need Google’s Product Sans font (aka Google Sans), which we, unfortunately, cannot provide for you. You can find a copy of the font relatively easily online, or you can replace it with Avenir Next, which matches it very closely and is included in Mac OS.


Download the Android 10 UI Kit for Sketch here.

Or for Figma, just go here:


Check out DeveloperTown's handcrafted Material Design 2 Kit and Apple TV UI Kit. You can also follow us on Dribbble!


Check out DeveloperTown's handcrafted Material Design 2 Kit and Apple TV UI Kit. You can also follow us on Dribbble!

October 10, 2019

Product Owners Need Sleep Too

It’s not easy being a Product Owner. You are responsible for ensuring that your products provide real value to your business and most importantly, your users. You have deep knowledge of the business strategy and market in order to help outline the product requirements for the team. You are the point of contact for almost everyone involved or interested in the project, and that can be overwhelming. How can you stay engaged, support the development team, keep your stakeholders up to date, and ensure the success of the project while still having time for, you know, sleep and eating? That other important stuff.

Well have no fear because we’ve got your back. Below, we’ll talk through a few tips and tricks that our busy product owners could use to make sure their time is maximized.

1. Detail the “What” not the “How”

With your limited time and energy, it’s more important to focus on defining “what to do” rather than “how to do it”. As a subject matter expert who knows the product, the team, and the business requirements, it’s understandable that you may want to help define how something should be done. Avoid giving in to this feeling. You have a team who will be doing the work and they need to be the ones to focus on how they’ll complete something. Your company hired them for a reason after all. By keeping your focus on what needs to be done, and allowing them to work through how it will be done, you empower the team while giving yourself the time you’ll need to deliver a complete backlog with effective prioritization. And maybe try that new taco joint you’ve been eyeing for months.

2. Provide Detailed Acceptance Criteria

Believe it or not but most people can’t read minds. As the rockstar Product Owner you are, you know this and should try to communicate as effectively as possible. The team needs to know what you require from each feature rather than making their own assumptions. (Didn’t someone say something about how assuming goes poorly?) If acceptance criteria are unclear, features may be implemented incorrectly, which never leads to good outcomes.

How can you ensure you’re providing all the needed details? Here are a few thoughts

  • Ask to add acceptance criteria review to your planning meetings. Take time to talk through each feature and what you think it needs in order to be complete.
  • Ask the team for help because it’s often easier to define what you want if you’re able to hear their perspective. Don’t be shy to ask if they’re able to supply you with their suggestions for acceptance criteria for any features you’re having trouble defining.
  • Ask one of your QA folk to review the stories. They’ll be testing them and can often provide invaluable feedback on how to write and provide better acceptance criteria.

3. Attend Scrum Ceremonies

Attending Sprint Review, Sprint Planning, and daily standups with your team is necessary for you to fully understand and be aware of the project’s current state. You need to be in the room to communicate with the team that a feature is truly “done” so that the team moves on from completed work, and does not linger on completed features. You will also know what is happening with the project and be able to effectively communicate current status, priorities, and next steps to stakeholders.

But what if you can’t attend every Scrum ceremony? It happens. In that case, here are some suggestions to make the best of your busy schedule:

  • Identify a “sub PO” and make them available to the team for day to day needs and to help get questions answered. Make sure you give this individual the authority to make decisions and the background to make sure those decisions align with your vision.
  • Ask your Scrum Master to group questions and needs from the team and set up a weekly meeting with you to review. Setting up a weekly time for you and the team to meet and review every week can make your life easier if attending the ceremonies just isn’t doable.

4. Having Your Cake and Eating it too

Product Owners are busy and with good reason. You’re responsible for ensuring the delivery of the right product at the right time, answering to the development team and to other key company stakeholders, while generally managing other responsibilities as well. In a perfect world, you would be available to your development teams at all times, but that is rarely possible. Life is busy and we’re all trying our best. But with a focus on attending scrum ceremonies, providing detailed acceptance criteria, and maintaining a clean backlog, you’ll be well on the way to ensuring the development team is provided with the information they need to help you deliver an outstanding product. And maybe even getting to finally take that vacation you deserve.

August 23, 2019

Is Outsourcing Right For You?

In my last blog, Choosing the Right Software Development Partner, I talked about finding the right partnership when hiring contractors and consultants. I focused on the WHAT of that partnership. Today I’m going to dig into the WHY, and clarify some of the big questions around outsourcing to help you make a more informed decision about when it’s the right move.

Doesn’t outsourcing cost more?

This is an easy conclusion to jump to when simply comparing raw project costs in the ideal situation (you have all the resources needed and they have all the required time, skills, and availability to complete the project). Since reality is not often ideal, there are many reasons to consider an external delivery partner, and one of them is cost savings. Here are some examples of when a delivery partner can help save your bottom line:

You have a project that needs completed, but your staff has no additional bandwidth.

Projects like this are extremely common, and the cost of completion comes in 3 flavors with their T-shirt sized project cost beside them:

  1. Staff an FTE (full time equivalent) team to complete the project (S)
  2. Hire an outsourced team (L)
  3. Mixed team (M-L)

Based on project cost, a full staff of FTEs may seem like the best option here. While all three options will get the job done, there’s more to consider than just the project’s delivery investment. Mixed and FTE teams come with ongoing expenses related to the new FTEs, which devour project cost savings very quickly. Additionally, these resources incur administrative overhead of mandated intake training/orientation that consultants and contractors are often not subject to. Once the initial phase of the project is complete, and you have evaluated the ongoing support needs, you will be able to more clearly gauge how many FTEs are required to keep things running smoothly.

Project completion requires skills and experience your staff doesn’t currently have

You can send your staff to training, and for something that is going to require ongoing work, you definitely should. However, when there’s a tight deadline, consultants and contractors offer a means of injecting your organization with the skills and manpower to bridge the gap as your team comes up to speed. In most cases, your delivery partner will provide shadowing and training opportunities to make the handoff to your team as smooth and painless as possible.

You need a Proof of Concept to get organizational buy-in

When the paper evidence just isn’t enough, building a proof of concept (POC) can make a very strong argument to fund a project. Unless you have the resources with time to burn sitting around looking for work, someone else is going to have to build it. Whether it’s a clickable prototype, process design framework, or any other kind of asset, outsourcing a POC can be a big win. This avoids the risk of hiring new staff with the skills to work on a project that may or may not get the green light. It has the added benefit of establishing a relationship with a resource who can be called on to produce the full product when the time comes.

Won’t the consultants take too much knowledge with them when they leave?

If you feel like this is substantial a risk, you have made the wrong choice in delivery partners. There is never a sure-fire way to get a 100% perfect hand-off every time, but truly excellent firms will work with you to transition as much knowledge and information to your in-house team as possible based on the long-term sustainability plan for your product or service offering. Depending on your deadlines and budgetary constraints, this may not be part of the initial Scope of Work (SOW), but is always something you should ask about and know what the plan is ahead of time to ensure everyone’s expectations are met. A couple different variants of this process exist:

  • Training sessions, provided by your partner, in the form of classes/seminars to get your in-house team up to speed and bridge knowledge gaps
  • Transition meetings where the focus is entirely on shifting current and ongoing delivery responsibilities to your team
  • On-demand support for your team. This option is typically in the form of a support contract, which is a whole different type of engagement, and not every firm is willing/able to commit resources to this kind of project

No matter the approach, the most important aspect of maintaining the deliverables once your partner’s involvement has tapered down is to make sure that you have the resources in place during the transition to pick up the torch for your business and keep things moving. The earlier the better!

How will I coordinate with outsourced resources?

There is a wide variety of options when outsourcing work, but don’t take “Outsourced” and “Offshore” to be the same thing. Here are the three main kinds of outsourcing, and what makes each unique.


For simplicity, offshore resources are generally teams based in India or other places abroad, typically not in the same hemisphere as your business (I chose India specifically because that’s where most of the offshore teams I’ve worked with are based). The advantage is usually clear here in the way of rates, as offshore resources tend to be much less expensive per hour than Nearshore or Local resources. The downside here is largely around logistics and communication. With a (literal) half a world between them and you, coordination can be a very big challenge, from meeting times to productive hours of the day, there’s challenges all around. Many delivery partners will provide a liaison to help bridge this gap.


Local resources are generally within a timezone or two of your business, maybe in your town, and possibly even onsite at your location either regularly or on a prescribed cadence. Local resources tend to be more costly than offshore or nearshore, but are great for several reasons, one of which is the fact that they are the easiest to coordinate and integrate with your team. They will also usually not require an additional liaison to bridge time, communication, or cultural gaps in interactions.


Nearshore resources are a kind of hybrid of local and Offshore, and that’s reflected in their pricing as well. Working with a delivery partner with nearshore options can help ease the cost of projects as a whole, and will usually still involve a local liaison to ensure that delivery is timely and expectations are met on both sides. The primary difference between nearshore and offshore is that nearshore tend to be in the same hemisphere as you, so these resources have much less trouble aligning meetings to typical business hours or getting on a call at some time of day that works for your people too.

So, is it right for me?

Unfortunately there’s no magic answer that works in every situation, but here is a quick set of questions to kick-start the decision-making process:

  1. Can we complete this in-house today?
  2. Can we deliver this in-house in a timeframe that meets or exceeds the business goals for this project?
  3. Will this project require ongoing support/development?
  4. Will adding outsourced resources cause internal friction within our organization?

If you answered “No” to all of these questions, there’s a good chance that an outsourced delivery partner could really reduce your delivery timeline and improve your ROI.

At the end of the day, it still comes down to evaluating the risks and rewards. The decision to outsource all or even part of your delivery team is always a very financially, and culturally, dependent process. Knowing where your project is most affecting your bottom line, understanding the project’s ongoing needs, and selecting the right delivery partner can mean the difference between good enough and great, or even success and failure.

June 4, 2019

Choosing the right Software Development Partner

Hiring consultants or contractors is a challenging process, and choosing the right partner for your needs is critical. In this article I’ll explore some key areas of partner selection, and how to determine the fit of a consultancy with your business.

Consultants or Contractors?

This is the very first decision you need to make to select the right partner. Many people use the words interchangeably, but these are two completely different kinds of resources. Choosing consultants when you need contractors can mean spending more money than you need to, and choosing contractors when you need consultants may leave you feeling like your money was not well spent.

So what’s the difference:


  • Skilled in production
  • Focused on task completion
  • Expects an environment where work is directed by managers
  • Does not need to understand your business


  • Works to understand your business
  • Treats your business like their own (Has the best interest of your business forefront in all recommendations and actions)
  • Focused on solving problems
  • Able to step back and see the big picture
  • Skilled in facilitating
  • Skilled in production
  • Committed to finding the right solution

There are a lot of differences between these two roles, and this acts more like a spectrum with most individuals falling into some balance between these two types.

Culture Fit

Finding the right cultural fit for your team is critical to the success of any hiring process, whether it’s the right FTE, contractor, or consultant. There are several important points to consider when weighing the options to add an outsourced team or supplement your own (apart from the price tag). Having the technical ability to do the work shouldn’t be the only consideration when making a hiring decision.

Consider these “non-production” factors when selecting a partner:

For Remote Resources

  • What is the onsite expectation (if any)?
  • What communication tools do you use to facilitate remote work?
  • If resources are in different time zones, what availability is needed during your business hours?

For Onsite Resources

  • What is the dress code in the office?
  • Is participation in corporate events expected?
  • Where will they sit?

Talented individuals and groups exist in a wide variety of ecosystems, and while these questions may seem somewhat basic, finding the right cultural fit with your partner will build a much stronger, more sustainable relationship for the long term while keeping both sides of the partnership positively engaged throughout the project.

Business Needs

A surprising number of partnerships end badly because of a mismatch between offerings and needs. You may have a referral from someone who thinks XYZ Agency “does great work”, but being an awesome consultancy or contractor doesn’t automatically make them the right fit for your business needs. Going into initial meetings with an open mind is essential on both sides of the equation. Look at the offerings from the potential partner and ask yourself the following questions:

What does success look like?

Have in mind what a successful outcome of your project looks like. Your partner will help flesh this out in the upcoming meetings, but the more clear picture you have going into the initial meetings, the more likely you are to find the right fit.

Can they do the work I need done?

This is a matter of competency. Does the partner have the necessary technical/delivery skills required to help reach your business goals?

Do their offerings align with and support my goals?

Even if the partner is incredibly qualified to deliver what you’re looking for, that doesn’t necessarily mean they have an offering to support you. Some partners have a process that they are invested in, and may not be willing to sell a subset of services to you. In most cases this is not due to a lack of flexibility by the partner, but a commitment to a process of proven success and a desire to deliver success on every project.

Wrapping Up

There are a lot of factors involved in selecting the right partner for your organization. Contractors or consultants? Individuals or teams? Project work or staff aug? And of course, cost. Always think beyond the needs of the moment, taking the time to understand the values and capabilities of your partner will make sure your choice sets you up for long term success. Make sure you understand the value your partner will be delivering, and how that fits with your organization and business goals.

May 16, 2019

The Promising Future of Design & Development Collaboration

At DeveloperTown, we constantly refine and optimize our workflow between design & development. We evaluate and kick the tires on any and every new tool that could help us blend the gap between our designers and developers.

Currently we rely on our trusty vector design tool of choice, Sketch for design. Invision is our go to for prototyping, but Sketch Cloud is looking very interesting these days as well. Lastly, we use Zeplin for developer specs and hand-off. This workflow has served us well but it’s not perfect.

  • Developers have to replicate pages that designers layout in a vector tool.
  • Our developers still have to translate design components into code
  • Iteration and design changes repeat the entire process over again
  • Interaction design tweaks can get lost in the process

Our current process.

Blending (not bridging) the Gap

For a long time, we were looking at tools to help bridge the gap between design and development. The problem with a bridge is that there's inherently still two separate sides of the process. The gap still leaves too much room for ambiguity. Instead of bridging, we want to blend the gap in order to bring design and development closer together. Closer teamwork makes the digital product design dream work.

Which new tool will blend the design / development gap?

.   .   .

Where we want to go…

Every time we have brought designers and developers closer together we have seen dramatic increases in speed and quality. The ultimate goal is for our designers and developers to work from a single source of truth. We turned our UX microscope on ourselves and came to the obvious conclusion that the design team and development team need to be able to look at the same problem in a way that naturally relates to how they tackle a project. When we adopted Zeplin back in 2015, it shaved a ton of time off of our handoff process and brought us closer together. We believe that one of the upcoming “single source of truth” tools will have an even greater impact on our productivity and team collaboration.

  • Developers build the right custom components as needed
  • Designers use components to layout pages precisely
  • Designers now own the interaction experiences
  • Faster prototyping and user feedback loops
  • Developers can focus more on optimization
  • Designers can maintain focus on user experience

In the end, this allows our developers to focus on crafting code perfection and designers to create a more perfect experience for the users. Everybody wins.

Consulting Hurdles in This New Era

All of these new tools and processes are really exciting, especially if you’re a company with a single product and cohesive design language. Since Developer Town and DT Starts serve a variety of clients from start-ups and scale-ups to Fortune 100 companies, we have to be cognizant of not creating a process that backs us into a one dimensional corner. Our process needs to be optimized with a common design language, yet flexible enough to accurately represent the individual identities and personalities of each client.

As Kilian Valkhof elloquently pointed out in his post “What Design tools get wrong,” future design libraries need to work for us agency designers too. This is where design tokens come into play in a big way.

Will our current favorite tools still have a place
in our workflow?

  • Do you need Invision when you’re already prototyping in code?
  • Does Zeplin’s role get reduced to only new custom components?
  • Do we need versioning tools like Abstract if the source of truth is in a repo?

The Contenders — Tools We’re Keeping an Eye On

So what does the coming wave of new tools mean for our future stack and how will it drive Design and Development even closer together? In Part 2, we’ll take a look at the contendors we’re considering for future workflows. Stay tuned!