Two software engineers and a manager enter a bike shed

It all begins with rewrites, so I’ll begin with a bold statement:

Don’t rewrite products, refresh products.

Rewriting a large project often leads to confusion about the direction of effort and how to get shit done, all the way from the top to the bottom of the organization.

When you commit to rewriting something, it sets a mood around the old thing and the new things. The old thing is smelly and I don’t want to touch it. The new thing is shiny and will solve all our problems. Okay so what are you going to do for the months or years you’re rewriting it? “It won’t take that long and we can replace it, probably, in 6 months”. If you don’t know programmers, 6 months is a magical amount of time we think we can get anything done “good enough”. Usually what happens though is you take longer, because unexpected things always come up. But finally you feel good about it. Except, there’s that customer who pays millions of dollars for some feature you don’t care about. So you spend the next half a year re-implementing these random but valuable things in an effort to replace the old one. But here’s the problem. That old stinky project is even stinkier, because expectations increase over time, people with domain knowledge leave or have been promoted to positions they don’t have to worry about it. Nobody wants to own the code they’ve written 6 months later, so there’s an unspoken understanding that if it’s 6 months old, it was effectively a different person who wrote it. It’s been popped from your stack, never to be found again. You scratch my back, I scratch yours, right? Okay getting off topic. The point is, incremental improvements on a single project almost always trumps a rewrite. If your engineers tell you a rewrite is a better choice, more than likely, you don’t have an empowering culture where they can manage themselves and introduce solutions (and sometimes technology changes) they feel will solve problems. Rewriting offers temporary freedom from the box. They may not know this, or know how to express it.

Rewrite time! Rewrites scare me. The opportunity to built from the ground up is exciting, but the cultural effects that come with it aren’t worth it, and the need for a rewrite exhibits a more glaring underlying problem. Either the developers lack experience and/or talent, or lack empowerment, or all of the above. And very few people are keyed into the problem, so everybody buys into rewrite being the solution. People will get caught up in waterfall vs agile and how they’re going to slice it (vertically, horizontally, angled, and mickey mouse shaped). That’s great but it’s not even about that. Not only have you put yourself in this position of maintaining 2 projects, but the new one doesn’t have feature parity (and likely never will because some things have been designed OUT of it), so the sprint tickets and goals are directed by upper management to try and get themselves out of the mess and costs associated with maintaining that old stinky app. And you‘re scrambling to prioritize and roadmap the many features outsiders now want in it. Aside: If you just told yourself, “I totally give my team freedom to dictate the sprints” and you have a deep backlog, but give engineers a priority backlog to choose tickets, stop a moment and take a real hard look at yourself. That is effectively no better than straight up dictating. Two software engineers and a manager now enter a bike shed…

It inevitably ends up with them trying to enforce some sort of process of filling the sprints up with “just the right amount of pressure”. The theory is if they allow for buffer, or stretch goals, people won’t be able to control themselves and will always use exactly the amount of time given on a task. So basically, trying to apply psychological reasoning to process. Or, worse yet, the idea is people will wait until having just enough time left to finish it before the deadline. Following that, the idea is we need to enforce more deadlines. And somehow the recurring 2 week sprint is the solution to that.

In my experience, if those are smart software engineers who are given the freedom to solve problems, they will solve problems. If not, this may happen when the people doing the thing aren’t all that interested in the thing. How does that happen? Do they not feel empowered enough to own the product, survey the problems, and find solutions all on their accord? As mentioned earlier, they have lost the ability to manage themselves, through lack of empowerment. Does it really make sense to try and use blanket process on the team? I don’t think so, that’s a bandaid. I think people are different and given freedom can find what works for them. Happy developers build better software. Corporations spend a lot of effort trying to make us happy, with snacks and perks and HR initiatives and salary, but very little on freeing up problem solvers to solve problems. “Second, distrust in employees hinders the delegation of authority. Leaders may doubt their employees’ ability to perform important tasks properly without close supervision.” — 7 Principles of Employee Empowerment

A sprint to solve a problem don’t revolve around an arbitrary amount of weeks. Sprint to solve a problem should be until the problem is solved satisfactorily. There can be contention as to what is “satisfactory”. What is good enough? I’ve been doing this long enough that you can’t often know what’s good enough until you’re there, so why spend an arbitrary amount of time on it? Usually, you’ll undershoot it or overshoot it. Usually a company will do one of these a lot and spend the rest of the time discussing why.

Refreshing the product is more predictable. You know where you stand. Priority is clearer, and you can empower engineers to solve the pressing problems. And you don’t scare the living shit out of your customers, who always seem to hate change, when you pull the rug from under them with this completely redesigned product (because rewrite = redesign, right? right?).

If you’re planning for something many months into the future, it’s not actually important, or you’d be doing it this month. Throw it out. That focus and energy will serve you much better today. Like finding your way out of that bike shed.

It seems to result in this never ending misunderstanding from both ends.

“Why don’t we try a 1 week sprint?”

“Oh god, I like 2 weeks”

“It feels like 3 fits us better”

“What we need is better estimates and a definition of done”

It gets really interesting when we, the programmers, are asked for the sprint goal, “What is the major objective of this sprint?”

What are we suppose to say when it’s a mishmash of things and we’re sprinting in different directions?

Maybe we should have tried 1 week sprints.

Hacker Noon is how hackers start their afternoons. We’re a part of the @AMIfamily. We are now accepting submissions and happy to discuss advertising & sponsorship opportunities.

To learn more, read our about page, like/message us on Facebook, or simply, tweet/DM @HackerNoon.

If you enjoyed this story, we recommend reading our latest tech stories and trending tech stories. Until next time, don’t take the realities of the world for granted!