Does the following sound familiar?

You found product/market fit and have since grown a small-to-medium size software engineering team. A few of your developers have been around for a majority of your application’s lifespan, but most of your team is somewhat new.

You hired additional developers because the cycle time was slowing. Your team is experiencing some growing pains. They’re focused on what’s next in the Product Backlog and keeping things stable for your end-users. They’ve been doing a pretty good job at that.

As new team members have come in, it’s been a challenge to solidify some of your processes around handling tasks like:

• Pull-requests
• Documentation
• Improving your tests
• Formalizing your QA process
• Mentoring
• Debating what tools you’ll use for what

Phrases like “technical debt” and “legacy code” show up in planning meetings but it’s not clear what should be done about that. You’ll find some time to deal with that one day. Right?

If we’re being honest with each other, just how important are those concerns anyhow?

Your stakeholders (or product owners?) have heard these phrases a number of times but don’t seem to “get it.” Your team doesn’t know how to best advocate for dealing with them. I mean…if they really cared about the underlying technical problems your team is experiencing, they would obviously prioritize them, right?

So, it continues to get tossed into the someday/maybe pile.

Someday.

Someday…your team will have fewer priorities on their plate and they can spend that spare time to address some of those issues.

The team stops raising these concerns. They assume that nobody really cares, or that it’s someone else’s responsibility.

A big problem — your Rails version falls behind

Eventually, someone raises a very specific problem. Your Ruby on Rails application has fallen a few major versions behind the latest stable release ( currently v6.0.x). Unlike most technical debt concerns, an overdue upgrade to your application’s programming language and/or framework is easier for engineers and stakeholders to get on the same page.

“The version we’re running on is no longer actively supported.”

“We will no longer receive ‘security patches’ until we update.”

“We should see some performance gains and ability to use newer features, too!”

Nobody wants their application hacked and/or data stolen and shared on the dark web — so the security angle is often the easiest-to-understand approach for getting buy-in.

The team agrees to start exploring an upgrade. Before you get too far ahead of yourselves, an engineer on your team volunteers to do a deep dive into exploring just how big of a project a Ruby on Rails upgrade might be. We always appreciate when someone raises their hand to be a trailblazer.

They create a new branch in git, begin bumping the versions, start trying to make sense of the configuration changes, wait…are all of our 3rd-party Rubygems compatible? Why are most of our tests failing? Wait, do we even have automated testing on that one critical component in our application? After a day or three of digging into this, something else pops up that your engineer needs to switch over to.

They can pick this upgrade up again next week. Next week comes and goes. It’s unintentionally fallen back on the someday/maybe list, again.

Sound familiar?

Upgrades are complicated…but perhaps not for the reasons you believe they might be.

From a technical level, there is an abundance of valuable information available online to help engineers work through coding updates that are required to perform an upgrade.

The primary problem tends to be with your team being able to gain momentum.

Upgrade projects are difficult to jump in and out of. We’ve heard many stories of how 1–2 developers got a week or two into an upgrade, then had to switch over to something else for a while. When it’s time to look back at the upgrade, they’re not able to quickly merge code that they and the rest of the team have been working on in parallel.

Reality sets in. Can you be successful at continuing to work on the application under the older version of Rails while also trying to get everything working in the upgrade Rails branch? Aligning these types of projects, in parallel, is difficult. Especially if the engineer(s) working on the upgrade are also jumping back into helping with the next priorities in the backlog.

At this point, your team searches online for someone who has more experience working on upgrades.

This leads them to find an agency like ours (Planet Argon) to ask the question, “Can your team handle the Rails upgrade for us? We don’t have the time to do it, ourselves.”

While we can respond with, “Yes, yes we can help you with that” …we’re becoming increasingly convinced that you shouldn’t delegate your upgrade to a team like ours. (At least, not quite to the degree that you might be thinking.)

Let’s dive into our arguments.

1. You’re underestimating the time commitment needed.

It seems straight forward. Your team has X hours/week to work on the Product Backlog. If you outsource the upgrade to another team, you might believe that your team will only need to spend a few hours each week collaborating with the external team. The conversation with stakeholders to discuss budgets is that it’ll have very little impact on your internal team’s velocity.

On the surface-level, it seems like a win-win for everyone. However, if you haven’t gone down this path before — you might not realize just how involved one or more of your engineers will need to be to help dig through problems that pop up during the upgrade process.

This is particularly true if there isn’t much in the way of accurate documentation or automated tests in your application.

“We have 150 failing specs related in this area of the application. How exactly is this supposed to work?”

“We merged in your recent upstream changes and noticed that your team is using syntax that will not work with the newer version of Ruby.”

“This upgrade is going to require that we replace the following Rubygems. Is that something that your team will be able to start transitioning to or should we try to do that ourselves? Again, how should this feature work?”

Knowing that some level of this will likely happen — you assign one of your more Senior Engineers to act as a Technical Lead/project liaison. It’s not their only project to oversee.

Is it a safe assumption that they can’t be 100% focused on the upgrade — because if they could, wouldn’t you just have them lead this themselves?

So…after the initial “We delegated this to an agency” honeymoon period, your Technical Lead is voicing concerns.

“This is taking far too much of my time.”

“I’m not able to focus enough on my own coding commitments.”

“I feel like we could have done this faster, ourselves.”

“I feel like a bottleneck.”

While every project is a little different, it’s been our experience that it is rare for our clients to accurately reserve enough time for them to also be involved in the upgrade project.

I wish we could say, “You need to be available at least 10 hours/week for our team” but it really depends on what state your application and team’s process is in at the moment.

This tends to be an ongoing discussion throughout each of our client relationships. It’s an ongoing struggle to achieve perfect harmony.

2. The great merge is going to hurt.

A logistical challenge with any upgrade project is going to be when the upgrade gets fully merged, deployed, and is considered done. Depending on how rigorous your testing procedures are (automated or not) when you hire an external team, there is a grey area where the upgrade is handed off to your internal team to take ownership of.

There might be changes to your hosting infrastructure, your deployments, your third-party tools, possible data migrations, etc. This shared area of responsibility, if not carefully planned out, can create some frustration points.

We’ve encountered several scenarios where our team will get the major upgrade bump essentially finished, but the client’s team will be focused elsewhere at the moment. They don’t have the time to have their QA folks focus on this area, in-depth, nor does it seem like the right time to get the project pushed to production.

Why not? Risk.

“There might be new bugs introduced…so we’ll wait for a quieter month in our schedule to roll it out.”

“This requires data changes and we need to test that out more before we push it out as rolling back will not be a good option.”

While we have a number of clients who have been able to efficiently roll out an upgrade, we’ve also several sit on an upgrade branch that we “delivered” for a few quarters.

As I’m typing this; I am thinking about a client we wrapped up working with nearly a year ago. We’re still not certain they finished rolling that upgrade out. Their DevOps team wanted to handle that and from a stakeholder perspective, “it’s nearly finished” seems to be equivalent to “no longer a big problem”.

“Thanks, we can take it from here!”

…but did they?

3. You have a process problem; not a technical problem.

Your team of Ruby on Rails developers is capable of handling an upgrade — when it comes to the code. There are many articles available to help guide them through the common changes between each major version of Rails.

It’s quite possible that they’ve even participated in a few Rails upgrade projects before.

What they might not have a lot of experience with is…

• Explaining to stakeholders why upgrades are important.
• Being able to track, measure, and report their progress throughout the upgrade.
• Knowing how to best divvy up upgrade work amongst multiple team members so they aren’t all trying to solve the same problems, in parallel.
• Getting multiple team members up-to-speed with the project.
• Figuring out a healthy way to rotate who is involved in the upgrades.
• Fighting the urge to debate a, “it would be easier if we just rewrote it.” conversation (hint: no, it wouldn’t).
• Handling the scenario when we need to temporarily hit PAUSE on the upgrade to shift gears to focus on another company priority (without losing too much momentum).
• Finding sanity when there are over 1000 failing specs and trying to debug and resolve that.
• Exploring ways to make upgrades safer and faster in the long-run. (ProTip: Setting up a dual-boot approach)
• Making sure you aren’t reliant on a single developer to see it all the way from start-to-end.
• Avoiding burnout when it ends up taking far longer than your team expected it to.
• ..and most importantly, not having the next upgrade get put off for another 3–4 years.

Depending on how your upgrade project pans out, it could very well lead to introduce some residual trauma amongst your team and stakeholders.

This is, ultimately, why teams like yours reach out to companies like Planet Argon. You want your organization and team to get over these hurdles as painlessly as possible.

There’s an illusion that once you get caught up — your team will be able to successfully be able to keep up going forward. If that were true, wouldn’t you have been able to keep up with the latest version of Rails from the start of the project, all along?

Unless you make a commitment to making tactical changes to your regular development cadence, you will end up in this painful position, again.

Okay, so what should you do?

First, you need to admit that you have a bigger challenge here. There is a localized goal of being able to cross off a sizable task from your todo list. It’ll probably feel great but if we’re being honest, we both know that you’re going to find yourself in a similar position, again, in the next 1–2 years.

This is where we strongly recommend that you approach this as a global challenge with your team. That is if you want to avoid having to come back and try and sell an upgrade to those controlling the budget in the not-so-distant future.

“Did we not just pay for a big upgrade a little over a year ago?”

We both know that conversation isn’t going to be met with a blank check. So, you’ll opt to wait another year. The price tag increases.

Focus on the processes that led to your team falling behind

What your team needs is a cohesive strategy and processes for your team so that this just becomes part of your team’s regular workflow and routine. What if we could automate some aspects to upgrades while also making sure that your team has the authority to keep moving things forward, without it needing to put the rest of the Product Backlog on hold?

What we recommend here is to outline a process blueprint for your team. A guide that will help your team determine who is responsible for what, the frequency of when certain updates should be made, and to maintain a regular scorecard to help highlight whether your software is starting to fall off the rails, again.

Pick a strategy for technical debt repayment — and stick to it

With the constant go, go, go of new product development, technical debt is the unglamorous work that gets sidelined indefinitely. We have heard stories about this over and over from engineering teams of all sizes on our technical debt-focused podcast, Maintainable.

A few recommendations:

• Mariah Howard: How To Discuss Technical Debt With Product Managers
• Upgrading Ruby on Rails with Eileen Uchitelle
• Making is Easy, Mending is A Challenge with Sandi Metz

Part of solving your ongoing problem is to give your developers time to fix these issues as they pop up. This might require specific members of your team to focus on technical debt or to have some sort of backlog system for this type of issue. Whatever strategy you pick, stick to it, and hold your whole team accountable — including looping in your stakeholders to set expectations.

Hire consultants to focus on the long-term problem, not a quick fix

Outsourcing the bulk of your Rails upgrade is a temporary solution to a long-term problem. If you want to avoid needing to outsource this type of work every other year or so, we encourage you to seek a team that can focus on helping guide your team through this process, yourselves.

We believe that your team is fully capable of getting these issues ironed out. Having worked on ~100 Ruby on Rails applications since 2005, we have a lot of experience tackling the upgrades. As much as we do enjoy rolling up our sleeves and digging into a big gnarly upgrade, we really believe that your team will benefit more from doing more of the underlying work themselves.

We’d love to show you how.

Originally published at https://blog.planetargon.com.

3 Reasons Why You Shouldn’t Outsource Your Rails Upgrades was originally published in Planet Argon on Medium, where people are continuing the conversation by highlighting and responding to this story.

Around a year ago, I was chatting with a good friend about an idea I had for a podcast. Over the last several years, I’ve learned that I’ve become really focused on improving existing software over building something new.

I’m not a maker. That is somewhat true, I prefer to spend more of my time improving something than making something from scratch.

The concept for the Maintainable podcast was to challenge myself with finding a diverse collection of experienced professionals from our industry — and to hear their stories about how they played a part in improving existing software.

While we, as an industry, are creating a ton of new things — we also need to be focused on making the existing things better today than we found them yesterday. We don’t need to label this as “legacy code” — it’s just code.

As of today, my team has helped me publish 13 episodes (with several more on the way). I’ve had an opportunity to speak with people like:

• Charity Majors of Honeycomb who thinks we need to spend more time “testing” in production.
• Eileen M. Uchitelle of GitHub on how to tackle a large Ruby on Rails upgrade.
• Matt Weagle, Engineering Manager at Lyft on coaching developers on how to better discuss technical debt
• Coraline Ada Ehmke, Principal Engineer at Stitch Fix on the role of empathy in the workplace
• Pim Elshoff a software developer at Procurious about communication tactics within technical teams
• …and several other people that I have learned a lot from.

Have you heard any of the episodes yet? (and find value in it?) If so, it would mean the world to me if you could take a moment to add a rating on Apple Podcasts. 😊

If you haven’t, I invite you to listen to an episode or two at Maintainable.fm.

Originally published at https://dev.to on July 9, 2019.

First off, do we really need — another — podcast about software development?

For a number of years, I’ve been kicking around the idea of starting a podcast to talk with people about software but really felt like it’s a saturated market. I kept telling myself that I wouldn’t pursue anything that was focused on a specific technology choice (i.e., Robby on Rails almost graduated to be a podcast several times over the last 15 years?). I also have very little interest in talking about “what’s shiny/new/hot in our industry”, either.

There are plenty of podcasts for that.

Last year, I found myself thinking a lot more about what starts to happen to software after it’s been through many different iterations, phases, engineering teams, and pivots. I’m really not an advocate of the BIG REWRITE and think that developers far too often find themselves starting to dread working on their code bases.

As a result, momentum slows down. Team’s get discouraged. People quit. New people get hired. More people complain about the state of the code base. More time passes…and the problems have become far more problematic than they ever needed to.

Does this sound remotely familiar?

I’ll be honest. You’re not alone.

A lot of us have felt this. In many scenarios, we’ve felt that the only way out of the problem is to quit and find somewhere with a better code base to work on.

However, there are tons of scenarios where the company has good intentions but their trajectory has compromised their technology decisions…a few too many times. What they really need is an advocate — from within — to help them start making positive steps to their ideal future.

I want to talk about “The Messy Middle” phases of software development. (btw, a great book by Scott Belsky). This is why the team at Planet Argon has helped me launch the Maintainable Software Podcast.

On the podcast, I’ll be speaking with seasoned veterans of our industry…who have seen some 💩 over the years and have been able to help organizations push through the problems often associated with technical debt and legacy code.

The first two episodes are now published for your listening pleasure.

On this first episode, I speak with Anna Filina about what technical debt is and how we don’t need to ask for permission to adopt better development processes.

On the second episode, I speak with James Smith about ways to measure the reliability and technical debt of an application’s code base.

FAQs

Q. How often will you be publishing?

A. I’m aiming for weekly releases (for half of the year… maybe a spring + autumn schedule).

Q. Where can I subscribe to Maintainable?

Great question! Here are a few places

• Spotify
• Overcast
• Apple Podcasts
• Stitcher
• via RSS

Q. What if I have some great stories to share?

A. If you think you’d make a good guest for the podcast, do get in touch with me via robby@maintainable.fm to pitch a topic or three.

Q. How can I help promote Maintainable?

A. Another great question, you ask the best ones!

You could share links on social media, follow Maintainable on Twitter, re-tweet links to episodes you find value in, post an honest review on Apple/iTunes, etc.

#BecauseARewriteIsWorse #technicaldebt #softwareengineering

Hello, Maintainable Software Podcast. was originally published in Planet Argon on Medium, where people are continuing the conversation by highlighting and responding to this story.

Cultivate our industry’s next generation of talent while improving your team’s mentorship skills.

Running tech internships at Planet Argon has become a regular activity. We’ve had nine separate interns this year (2018) alone and will have around the same number next year. We’re a small company (< 12 employees)…yet we find a way to make this work well for our interns and ourselves.

One of our business goals is to be seen as an example for running great internships and to “open source” how we do it.

We know there are a lot of organizations that are intern-curious but don’t know how and/or where to start.

…which is where I found myself back in 2009 when I tweeted:

Robby Russell 🐘🚂 on Twitter

Anybody have experience overseeing interns? We've been reluctant to do it in the past because we aren't sure what is expected...

A decade later, I’m delighted to share our philosophy and approach to running a great internship with you.

Are you considering bringing on an intern or five in 2019 and aren’t quite sure where to start? OR are you want to streamline an existing internship program a touch?

Today I’m delighted to share the Planet Argon Tech Internship Toolkit with you. It’s free.

We touch on how to a) recruit interns b) how to onboard interns c) how to challenge interns d) how to learn from interns and e) how to send them off into the wild — ready to get their new career started.

Today is my birthday and this is my gift to you.

Read and/or download the toolkit

Should you find some valuable tidbits in the toolkit, please consider sharing it with your peer networks.

P.S. a huge thanks to all or our past interns for helping each of us become better versions of ourselves.

This was originally published on blog.planetargon.com.

🎂 My birthday gift to you. The Planet Argon Tech Internship Toolkit was originally published in Planet Argon on Medium, where people are continuing the conversation by highlighting and responding to this story.

• The State of Test Coverage in Rails
• Keeping Ruby on Rails on Track with Containers
• Code Quality Matters in Rails

In addition, I’ve prepared a short video presentation to talk through further data points that were a bit surprising…while injecting my take on what might be contributing to them.

Are Rails developers keeping their apps updated? Is Ruby on Rails attracting new developers? What RubyGems are keeping developers awake at night? …is Ruby on Rails dying?

If you’re interested in learning more about the state (and history) of the Ruby on Rails community — visit http://rails-hosting.com/

What were you most surprised to learn about in this year’s survey results?

Robby Russell is the VP of Engineering and a partner of Planet Argon, a Ruby on Rails development firm based in Portland, Oregon.

A few related articles:

• 7 Steps to Take Over an Existing Rails App (Before You Write A Line Of Code)
• Healthcare on Rails: Why these 10 companies chose Ruby on Rails
• Ruby on Rails Code Audits: 8 Steps to Review Your App

Insights: 2018 Ruby on Rails Community Survey was originally published in We’ve moved to freeCodeCamp.org/news on Medium, where people are continuing the conversation by highlighting and responding to this story.

When I’m in this mode — I try to remove music with vocals so that I can focus on my task on hand and less on the stories being shared. So, I tend to always be on the lookout for new instrumental music to put on as my daily soundtrack.

Recently, I decided to start curating a few new playlists and wanted to share.

Here is one that now has over six hours of music from instrumental post-rock bands from around the globe. You can listen along on Spotify here.

Also, disclaimer… my band, “The Mighty Missoula” shows up in here, too. ;-)

Let me know what you think! Do you have a favorite playlist to listen to while working and/or focusing? Share a link below. 🙃

The majority of Ruby on Rails applications that we provide long-term maintenance and development on are inherited. Our clients usually bring applications to us that were originally built by a freelancer, in-house developers, or another agency.

Over a dozen years of working on apps, I believe we do our best work when improving and evolving existing Ruby on Rails application.

One of the best aspects about Ruby on Rails community is that when conventions are followed we’re able to dive in fairly quickly to an existing code base and have a sense of how things fit together.

But inheriting a “legacy” Rails application requires a certain few steps before you ever type a line of code. It’s impossible to accurately estimate the amount of time it will take to accomplish a task, let alone actually complete the task itself, without taking the time to explore and understand how the app is currently architected and working.

So what does our process look like before we begin working on an existing Rails application?

Here are seven steps that we take when we inherit a legacy Ruby on Rails app, why they’re important, and how these processes support our ability to improve our clients’ products.

Step 1. Have the stakeholder(s) explain their business

We do this through a series of questions in our initial calls with a potential client. Depending on the company, we meet with anyone from marketing managers to designers to directors of technology. Here are some of the questions we ask about in our first few conversation.

• What does their business do?
• What industry do they work in?
• Who are some of their biggest competitors?
• How do they make decisions?
• How would they describe their company culture?
• How does this application fit into their software ecosystem?
• Do their customers interact with it?
• Do third-party vendors/partners need to interact with it?
• And/or is this primarily for behind-the-scenes operations?
• Have they developed APIs within the app that need to be exposed for external and/or internal tools? If so, who relies on those?
• Does this application facilitate any financial transactions?
• Does this application store any extremely sensitive data? (i.e., Health records, billing information, personal data, etc.)
• Is it mission-critical? If the project went down in the middle of a Saturday evening — what impact would that have on their business?

Step 2: What isn’t working?

Every client, with an existing application, comes to us with a story of things that have worked well (and not so well) with their application.

• Are their areas of their app that seem brittle? Are there pieces that seem to repeatedly break, get fixed, break again, get patched, break, rinse, lather, and repeat? This could highlight an area of the code base that might be really complicated and/or under tested.
• Are there features that were developed that nobody appears to use? Is this an area that could get removed and/or does it need to improve so that is becomes useful?
• What area(s) of the application do they dread having to deal with? What parts of the app are they complaining about — or they have an ongoing joke about dealing with?
• What area(s) of the app did they end up creating “creative” workarounds for? This could hint at a poorly designed set of features — perhaps an area to improve at some point.

We document this for future reference. An important aspect to our job here is to listen. These pain points might not be at the top of their priority list at the moment — but at some point, these areas would be good to raise in the future.

Four months later, asking a question like, “Hi Sarah — is that importing tool still a pain in the ass for your team? Should we take a look into that in the near future?”

Humans have a funny way of just accepting and getting used to annoyances in their software. It’s our position that good partners listen for that and find ways to make their life a better — even if it’s as minor as making a textarea box a little bigger so that they aren’t having to type several paragraphs into a text field or cleaning up an awkward navigation pattern. Sometimes, we get the biggest thanks for the smallest of solutions.

Step 3. Get a walk-through of the application

Before we start diving too far into the code base, we’ll schedule an in-person or screen sharing meeting and have our new client walk us through their web application. We record this session, if possible, so that we can go back for reference and/or onboard other team members to the project.

This is really helpful to connect back to their user roles and business goals. As we will not have time (nor cognitive ability to remember) to dive into every nook and cranny of the application, we typically ask them to demo the 2–3 tasks that each role needs to reliably interface with.

During this process, we’ll take notes on their user roles, document these in Confluence, and determine which stakeholders would be best to approach if we have further questions about the application. For example, “Maggie is a good point of contact for their reporting tools”, “Geoffrey is a good point of contact for their data importing features”, “Lindsay appears to know the most about their API functionality”, etc.

Our aim here is to supply our team with useful information so that they can reach out to the right people.

Step 4. Show us your backlog

From here, we ask to see any existing backlog documentation that the team has in place. We’ve seen clients approach us with access to their existing Pivotal Tracker account, JIRA Kanban boards, huge spreadsheets (we see this far more often than you’d think!), a list of requests in an email, or formal PDF documents that outline thorough user stories and mockups.

More often than not, we typically move our clients into our own JIRA Cloud account and help them import and/or add tickets for us to begin prioritizing. While some clients may want to keep their history intact, migrating future to-dos into one cohesive system is the most efficient route forward. Here are just a few things we love about JIRA.

Step 5. Document all the things!

Before we start coding, we need to get a lay of the land. Some of these are asked and determined when we conduct a formal code audit/review of their application. Others we will ask in early meetings.

Here are a few of the application specifics that we’ll document.

• Is it hosted on Github, Bitbucket, etc.?
• Will our developers need to interact with a VPN? Who are our primary contacts to dealing with any access/permissions there?
• Do they have any architecture documentation, mockups, etc?
• Where is the application being hosted? (Heroku, AWS, Rackspace, EngineYard, internal servers, etc.?)
• Do they have staging environments? How closely do these match their production environment?
• Does the application run through any CDNs (Akamai, CloudFlare, CloudFront, etc.)
• Do they have any performance monitoring tools in place (New Relic, Skylight, Scout, etc?)
• Are they using any automated bug reporting tools (Bugsnag, Airbrake, Honeybadger, etc.)
• Is their documentation on how their existing developers have been handling deployments?

Step 6: Audit the Ruby on Rails code base

We’re firm believers that beginning a new partnership with a thorough code audit of an existing application is a solid way to start on the right foot. When there aren’t crunched timelines to begin new development, we’ll begin development with a flat-rate audit of the Rails application’s code base.

This audit gives us more information about potential security and stability issues that may not have been uncovered previously. It also documents how the application is structured. After a code audit, we know tons more about the application than we would without one — and usually, the client learns a lot about their application as well.

We’ll keep it brief as we’ve written about code audits extensively before. You can read about eight steps we take when auditing a Rails application for more information.

Step 7: Start coding (on something small first)

Before we dive into any of the big updates that our new client desires, we always try to identify a small update (i.e., that we can code and test within a few hours). The aim here is to have a test run through our communication tools, stage the update, get approval from the client, push to production, get final approval and close out the request.

We tend to spot small issues with server access, communication between our teams, and/or need to provide some more training on our tools. After we’ve collectively built up some confidence — we are able to then start tackling bigger ticket items.

From my perspective, this ease into it approach is so vital early on. If a client has an urgent bug pop up a few days into our relationship — and we’ve yet to demonstrate to them (nor ourselves!) that we can successfully push an update to their environment — we might not be able to respond to the issue quick enough.

Closing Thoughts

At this point, we should have a decent understanding of how our new (to us) client’s business operates, how their existing Rails web application fits into that, a general idea of what it offers them, how critical it is, where it’s hosted, and what technical debt we need to be mindful of. From here, we can start diving into their backlog and checking off their feature requests and fixes.

Do you have an existing Rails application that you’re looking to rebuild, redesign, scale, or update?

We’d love to talk to you about your project challenges and goals. Click below to schedule a call with us.

Originally published at blog.planetargon.com.

7 Steps to Take Over an Existing Rails App (Before You Write A Line Of Code) was originally published in Planet Argon on Medium, where people are continuing the conversation by highlighting and responding to this story.

Confession. I have become bored with most startup entrepreneurs.

Lucky me. I have the benefit of meeting a wide array of business owners and stakeholders. Getting to speak with these folks is one of the great joys of running a software consulting company.

…but I have a confession. I have become bored with most startup entrepreneurs.

A decade ago, you could find me enamored with a budding startup founder’s vision. I would be enthusiastic about most of their projects. So many innovative ideas were getting pitched, started, and built.

Reflecting back, I am reminded that most of those businesses no longer exist. I still have a lot of admiration for those who were taking a huge risk, though.

Now, I find myself dreading a call with a budding startup entrepreneur. They’ll share their great idea and will say, “we intend to become the (insert ‘successful’ app/SaaS name here) of (insert niche industry).”

• “We’re going to become the Instagram of HIPAA Compliance”
• “We’re building the Tinder of Linux IT Security.”
• “We’re making a better Uber for Halloween Costumes.”

Oh, is that so? Cool. (sigh)

I’ll often respond with a, “who will be your first customer? …and how will you meet them?”

If their response is something like, “we’re going to invest heavily into content-marketing and SEO,” …I get cynical.

Note: an ideal answer would be, “we’re going to track down a few target customers, introduce ourselves, and begin building a relationship with them.”

While I see a lot of value with content marketing and SEO, I strongly believe that these should be how you attract more customers; not your first ones.

These startups are trying to solve problems for hypothetical customers. They’re investing in an experiment. They’re not running a business…at least, not quite yet.

While I do enjoy experimenting, I prefer focusing on incremental improvements these days. (I suspect this has a lot to do with where I find myself, as a business owner, these days. Iterating on an existing set of systems is completely different set of challenges)

Contrast this with having an established business call upon your team’s skill-set. A company that needs you to help them solve focused problems that they’re currently facing. A company that has been butting their head against pain points and need a fresh set of eyes on the problem.

This is where I get excited. I love getting to understand how different businesses operate.

• How did they get to where they are today?
• How do they make decisions at an organization?
• How do they measure success?
• How do iterate on their business model?
• How do they sell and market themselves?
• What has and has not worked for them?

During every prospective client’s sales cycle, I will ask myself the following question:

“What can we learn from their business that might help us with our own?”

There are a lot of lessons to learn from startups but they don’t seem to interest me in the same way anymore. I’ve become cynical of the startup culture over the last decade. Unfortunately, I’m not capable of faking excitement when it doesn’t exist.

Another important reflection on our past client portfolio. For several years, we’d see startups launch and go out of business within 2–3 years. Money would run out and the founders would go onto their “next big idea.”

It’s hard to maintain enthusiasm about building a portfolio that might resemble a graveyard five years from now.

A decade ago our average client relationship might last one-to-two years in length. We now find ourselves celebrating clients who have been with us 3–4x times that.

If you’re a consultant and rely on building longterm relationships — selling to a fresh startup is a bit of a crap shoot.

Dear Startup, I admire your gumption and wish you the best with these next steps. Let’s reconnect in three years. Perhaps we can help you with the next phases of your business. Love, Robby.

Why I Don’t Sell to New Startups was originally published in Planet Argon on Medium, where people are continuing the conversation by highlighting and responding to this story.

Turning Big Decisions Into Short-Term Pilot Programs

In a board meeting recently, the organization shared their desire to drop a program. As they shared their rationale, I reflected on the conversations a few years prior. At that time, the organization wanted to address a large pain point in their operations. We had many discussions leading to an approval of an investment of time and budget.

Two years later, we found ourselves questioning why it was a surprise that it hadn’t been the success we hoped for.

The organization lacked a clear consensus on how we would measure the program’s success. Most of us have found ourselves in this position before, right?

In general, I was comfortable with the program getting canned. But, that wasn’t the difficult part of the equation. The challenge was now on ensuring that all stakeholders understood the decision, too. The staff had grown accustomed to the program being available to them.

When it comes to decision making, it is harder to decide to stop a program then it is to decide to start new one.

Through these discussions, the lesson learned was that we should have framed this as a “pilot” program.

By classifying it a pilot program, we would have needed to discuss and answer the following eight questions:

1. What problems do you believe this will solve?
2. What would success feel like? (yes, feel.)
3. How (and how often) will you measure the success of it?
4. Who is responsible for measuring that success?
5. How can your team contribute toward its success?
6. Who is accountable should it not work?
7. What would it take for you to abandon it?
8. How long will you accept inadequate results?

When you pilot a program, the stakeholders know it could go away if it does not meet the defined objectives.

Like a TV pilot, the studio, cast members, and production staff know that there no guarantee it’ll get picked up. Yet, they’ll make sure they contribute to making it as successful as possible.

It’s the subtle difference between announcing, “Hey team, we’re going to do X from now on.” versus, “Hey team, we’re going to pilot X. Here is how we’ll measure it and how you can help us make it work.”

Reflecting on many decisions that I’ve been part of, it’s easy to lose sight of the potential conversation you may need to have amongst yourselves at a later point. Recently, I’ve started to keep a list of “Pilots” that I have in play that have yet to get picked up for a full season.

If you’re not quite ready to commit for the long haul, consider a pilot.

Two years ago, we signed the Portland TechTown Diversity Pledge with a number of other local tech organizations.

At the time, we were ignorant on many aspects of the issues in our industry.

Today I say, with confidence, that we’re less ignorant of the issues. But we still have a long way to go.

Earlier today, Prosper Portland published the results that outline the progress (and non-progress) of Portland’s tech community over the last two years.

Our team was able to contribute to this project by donating time to design and develop a microsite to highlight the results of this year’s research findings. We invite you to take a look at the 2017 Portland Tech Diversity Survey results.

Since we signed the pledge, our nearly all of our team has participated in Unconscious Bias Training and other inclusion workshops to discuss ways to put best practices into play.

From a hiring perspective, we’ve revisited our recruitment process starting with the job ads themselves, how we review resumes and applications, and how we grade and discuss interviewees as a team. The entire process has become more formalized, clearly documented, and the entire team is now on the same page.

We’re a small company and not anticipating a massive hiring spree in the near future, so we’re focusing on other ways to promote diversity and inclusion.

We have plans to connect with local youth in our community through volunteering, mentoring, internships, and sponsoring programs over the next year. The underlying goal of our involvement in these programs is to show the different types of career paths young people could explore with some real-world examples.

I’m encouraged by the small progress that the Portland tech community has made in two short years, and motivated by the areas where we haven’t seen progress to continually work harder with the Planet Argon team for a more inclusive and diverse environment.

Originally published on the Planet Argon Blog