For the second year in a row, I had the privilege of attending Ops Conf. This conference is a semi invite-only conference focusing on founders and executives of small (under 200 employees), boutique software consulting companies.
Remember the glory days? Your company had it all! New signups every day. Coverage on the hottest blogs. Money was rolling in hand over fist. All thanks to your hot app. You and your goons really nailed it when you followed an MVP process and built just the thing the market was looking for.
But then something happened. You shifted focus to integrating with another company's API. Or you lost your entire developer team. Slowly, kudzu vines covered over what was once a glorious app. The technology you used to build grew outdated. Bugs accumulated, but there was no time to fix them. You shed a single tear when you thought back to the glory days.
Finally, a new day dawned! You got a funding round! You've just hired a new team of developers. They start next week. You can't wait to get them slinging code. But are you ready? Starting a new team on an old app isn't as easy as handing them laptops and saying "clone down the repo". In this post, the first of a two-part series, we'll take a look at some advice you can use when ramping up developers on code in a legacy application. When we're through, you'll be ready to let the good times roll again!
In this blog post I'll highlight some of Quick Left's most effective BI software tools in the hopes that you too will see how internal business intelligence tools can help your organization. Is time for you to build an internal business intelligence tool?
While we know there is much year left, we wanted to recap some of the great blog posts that have been published during 2015 so far. So please, grab a warm beverage and enjoy some strait-up, Quick Left nerd wisdom.
When building software iteratively, feature planning has to be done early and often. But it can be a complicated process due to all of the stakeholders involved, each with different viewpoints and goals.
What's more, it's easy to overlook key behaviors of a feature, which can lead to expensive and rushed code later. It's usually intuitive to figure what should happen when everything goes according to plan, but what about edge cases? What should happen when a user supplies bad data? A hacker launches a malicious attack on our application? What about when chaos makes the whole system unstable?
In the first post of this miniseries, we'll take a look at one way to get everyone's voice heard in the planning process, including the product owner, developer, designer, and QA engineer. Using this approach, teams can draw on their diverse perspectives to tease out a detailed blueprint of a feature that costs less and performs better.
- ← Previous
- Next →