As a software engineer, I know how frustrating it can be to work with legacy code, especially when your client has no idea of the level of technical debt you are inheriting, and wants you to deliver bug fixes and new features as soon as possible. If you’re as passionate about software development as I am, you’re supposed to enjoy it, not hate it. That’s why I’m writing this blog post: To share my experience and a key piece of advice about how to deal with it.
The most common issues of working with legacy code are:
- Having no tests at all, or no useful tests.
- Outdated dependencies.
“Geek out” might seem like a strange and vague company value, so why write an entire blog post about that value alone? I recently met with a consultant who came down to our main development office in Colima a few months ago, and we were discussing her experience with us. By comparison to different service firms in Mexico, some who have their employees drink the Kool-Aid, she felt that a key advantage for us is one particular cultural element: Geek Out.
When I wrote our company culture document a few years ago, I put a lot of myself into it, based on my reality at the time and my aspirations for what a nearshore product development shop...
Curious about senior recruiting and communities? Here’s a talk I did at Hirepalooza 2015. Here are the Hirepalooza 2015 slides, which might help, given a couple jumps in the video. This is the description from the talk:
Even if you have a limited budget you still need to recruit tech talent. Join Eric Siegfried, CEO of TangoSource as he talks about how to find and hire the most critical technical talent on your team– even when you have close to no budget. From this session you’ll learn how to build and leverage an ecosystem, relate more to senior talent, and raise the level of your team.
Some people underestimate sprint retrospective meetings and think of it as simply the time when a sprint ends and they can move on to what’s coming next week. But in reality, this meeting provides an opportunity for the team to identify relevant action items to improve their performance. This is the moment where the team can meet and examine each other’s performance for the sake of the project. It’s also an opportunity to update and improve the team’s definition of done.
There are many ways to lead a retrospective meeting. I’ll share with you what has worked for us.
At the beginning of each meeting
Make the purpose of the meeting clear for everyone. If this is the team’s first retrospective meeting, it’s...
Have you seen a team that doesn’t understand the reason behind developing certain feature? Have you had a sprint review where more than a half of the features are rejected? Or that the team develops a huge feature that doesn’t add any significant value to the product? If you’ve seen this in your project, it might mean that your Product Owner is doing something wrong.
We can consider the Product Owner to be the main stakeholder. She should own the product and determine direction. The reality is that the Product Owner role is different from that of a project manager, since she has the passion, the vision, and, unlike a project manager, has to say no to people. Let me explain.
We’ve been working with Heather Poon to provide open source art for a top down zombie shooter game. It is covered under the Creative Commons Attribution Share Alike 3.0 license
For those of you who happen to look at other parts of our site, like the portfolio, you may have curious about our personal productivity tool, Todo Zen. It’s a great example of a viable product that was too slow to the market to make an impact, derailed by the success of an incompatible business. So what happened, and what can you learn from our experience?
Todo Zen origin
After trying out our first product that was getting limited traction in a small market, we realized it was time to move on. My cofounder, Federico, suggested that we try creating a task management tool, and introduced me to Kanban. That evening, we went to a restaurant, and wireframed...
Team extension (noun):The service category of helping companies scale their staff with remote contractors who integrate into the current business process.
So where did this term come from? Back in 2009, after a few months of working part time on my first software product, my company announced a voluntary layoff program, due to the excess software engineers in the organization. Within a day, I signed up to sign off. With some self funding, I had an 18 month window to try to find a profitable business after I found a technical co-founder.
During that time period, we killed off one product, started a second, and finally found a working business model, by paying attention to how our business was actually performing....
When you’re trying to create a new product as a non technical person, it might seem easy at first, until you start looking for real technical partners. Either you need to pay more than you can afford, or they simply aren’t interested in what you want. As a potential technical co-founder, there’s often so much work that has to be done before an idea gets validated, it sometimes feels like you’re on your own, with a non technical co-founder just waiting for things to happen.
Creating true partnership is what’s required to if you want to offer your deep gifts to the world. For myself, it took a while to find a real technical partner. Hopefully this post will make...
Does free work sound like a bottomless pit of time expenditure, with no chance of compensation? Have you ever wondered how to do pro bono work in a way that not only improves the world but helps out your bottom line? Our team just released some pro bono work for Vittana, which I think was time well spent. Below you can find out how it came about, why it was worthwhile, and read some lessons learned to improve the odds of success for your next pro bono project.
Discovering the project
When I ran into my friend Kenji at a mixer a couple weeks ago, it seemed like a usual incidence of our paths crossing, given that in one...