9

Became tech lead of a startup a few months ago. Software development is under Product in the org chart.

Even by startup standards the codebase I've inherited is poor. Example: the dev team took three weeks to update static text in the footer of the site and even then they gave up after 80% of the pages. Updating the footer's 'reusable component' breaks some of the templates, they can't tell why, even though they've been working with the code for months. The original contractors are of course long gone and left no docs behind.

I've gotten buy-in to clean stuff up, write stuff down, and reduce tech debt, but, of course, first we need to build a new medium-sized feature, that will involve the whole stack. We know this is a step towards other bigger features. The codebase seems full of abandoned, half-finished features, so I got buy-in for one of the devs to spend five days exploring the code and coming up with different approaches, rather than going with the first idea in someone's head.

On day three of five, product manager asked the dev for progress - short answer, here are some ideas we could do, but hasn't a clue which are any good yet as the code is a mess, there was a site outage on day two to deal with, and he needs more time. That evening the manager junked the spike and replaced it with a "prototype", based on one of the ideas. In doing this they, the product manager, made several technical decisions on the spot, pulling rank on me, the tech lead. From this and other incidents, I'm pretty sure the "prototype" will quickly end up going live, after a quick "does this look OK to you?" test on the dev's Macbook.

I get the whole "agile startup" thing. I get the relaxed attitude to risk and the need to get something, anything, into the hands of users last week. I don't mind having rank pulled on me.

But... I was explicitly told "we're a startup, we're not into this investigation ****" - "research" was spoken like it was a dirty word. I also appreciate more why the codebase is the way it is.

Old hands will spot this looks a case of the product being poor because the processes are poor; possibly from the org culture being poor. Stood in the trenches, this looks the worst case of "agile means make it up as you go along, learning from our mistakes is for losers!" that I've seen.

How can I convince the manager there's value in some planning and aforethought? Or, perhaps, should I be convincing myself that this is what this agile startup "should" be like?

  • It's not "learning from our mistakes is for losers!". It is "agile means make it up as you go along and increment on it!" As long as they add test to the "prototype" and it passes tests, then it should be ok. – imel96 Nov 6 '19 at 1:20
  • 3
    Ask them if they know what "technical debt" is, and if they ever plan on paying it down. Based on your description, they have a mountain of it. – Robert Harvey Nov 6 '19 at 2:10
  • 1
    When they hired you as a tech lead, what were there expectations? Are you replacing someone who left? Did they have to deal with this as well? – Robert Harvey Nov 6 '19 at 2:14
  • 1
    A lot of people imagine managers of this sort just don't realise how bad the code is. The reality is that most have the attitude of the Dick Jones character in RoboCop - "who cares if it works or not?" - and they have (rightly or wrongly) other concerns at stake. – Steve Nov 6 '19 at 7:48
  • 1
11

There are a couple of key points to get out of the way:

  • Agile != lazy development
  • Spikes and Prototypes are not interchangable ideas
  • Nothing that you described above is prescribed by agile or scrum

To your question about how to make your case, it depends on their real motivation. If they don't understand the impacts of what they are doing, you can make a case around the impact of technical debt on the ability to quickly deliver new features. If, on the other hand, they are simply using "we are agile" to cover up poor development and business practices, there is no argument you can make that will change things because they already know and they don't care. Now, I've seen a lot of both, so I'd encourage you not to assume one or, if you must, chose the optimistic option to start.

Technical Debt

The way I've seen the most success in arguing for technical debt is this:

You have X amount of time in a sprint. With a high level of technical debt, let's say that 40% of your time goes to managing your technical debt and 60% goes to new features. If we are great at development, maybe that pile grows slightly. Let's pick a number and call it maybe 1-2% per sprint. However, in a startup, we have to pivot fast and a lot of time we end up accidentally incurring a lot of technical debt, so even a good startup team might be incurring another 5-10% in a sprint. Of course, if you aren't trying to work well, it could build way faster. If you aren't cleaning up that technical debt, it just builds. Soon, a change that should be taking a day or two is taking 3 weeks (sound familiar)?

At this point, you can come off as helpful or a curmudgeon, and it really depends if you empathize with them. It would be great if you could just stop and fix old problems, but the organization probably won't, so let's find a new solution. First, you need to stop incurring technical debt so fast. Effective quality measures including unit testing, code standards, and code reviews are critical. Then, you need to start paying down the debt you've already incurred. Maybe code-cleanup Fridays with ice cream is something that the company can absorb. Also, targeting areas where the most new feature development will need to get done will help demonstrate how a cleaner code-base pays for itself with faster feature delivery.

Planning/Analysis

In your question, you seem to conflate technical debt and analysis. So, in case it's useful, you may also need to sell them on this. To do so, it is important to understand that there are complicated and there are complex problems. With a complicated problem, an expert can, in short order, analyze the problem and identify a good solution. The best data structure to store entries from a known form is a good example of this. In complex problems, there are a lot of unknown factors or the way that the different factors impact each other is difficult to predict. This requires experimentation and observing results. No amount of analysis will lead you to the answer, you have to get in there and try something. Knowing what type of problem you are solving is critical.

This is also distinctly different from iterative development, which is more a matter of solving pieces of the problem rather than tackling a whole large problem at once.

Hope this helps. Good luck, and I hope the people you are working with are just unaware of the impact of their actions.

| improve this answer | |
4

You can't because there is no value to them in planning.

The PMs will get credit for finishing projects on time and budget, not on how well the product works.

What you can do is trick them into adding more requirements before the work starts. eg "works on a PC".

It's the more nuanced requirements which drive good programming practices. Not "quality" or "doing it right"

It sounds like you need requirements such as "works with the template system" and "zero down time deployments" to drive some of the refactoring you want to do.

If you can get the right requirements, then fixing the code becomes the project and the PMs work for you rather than against you.

| improve this answer | |
2

"How do I convince..." questions assume you are right and the product manager is wrong. From the framing of your question it doesn't look like you have made a big effort to understand the reasoning of the product manager. But consider that the product manager might have a bigger picture. As developers and tech lead it is you duty to have an understanding of the business constraints you are operating under.

As you explained the story, the product manager saved two days of research by making a quick decision. You also state you understand "the need to get something, anything, into the hands of users last week." Given these premises, the product manager appears to have made the right call.

Given that you have buy-in to use some resources for clean-up, it seems management do understand that there are trade-off involved in such quick-and-dirty solutions. So what is it you want to convince them? That you should always spend three days on research regardless of the criticality of the fix or feature to be developed?

Time to market might be critical for a startup. Lets say a tech startup is at a critical juncture - if you continue user growth for a month, you will get major new investments. If growth stagnates, the business has to close. Under such circumstances, a startup will willingly accept technical debt - you optimize towards fast delivery of features at the cost of long-term maintainability. If the business closes, the question of long-term maintainability is moot. If it gets successful, you can hire more developers to clean up the mess.

I think the first thing you should do is to have talk with the product manger to better understand the constraints and priorities you are working under.

| improve this answer | |
2

Take a close look:

enter image description here

There! A picture paints a thousand words, don't they say? Well, don't take this chart at face value, it's just an illustration, but of very specific things.

  • The first case (line passing at the bottom of the striped area) represents the case, where you start out carefully, adopt proper patterns and practices, devote the necessary amount of time to plan ahead and design. You avoid technical debt by spending an additional small amount of time to pay it off "at birth", so that you don't accumulate "interest".

  • The second case (line passing at the top of the striped area) represents the case, where you start out carelessly under much pressure, so you need results now, and cleanup later. In that case, no matter how experienced you and your team are, all you can do is just keep the interest on the technical debt down. But it accumulates as time goes by.

I am focusing on these cases because you seem to fall under the second case. I would go as far as to say that this is a rather typical "deal" with startups. You either take time (and resources) to shine, or you get results fast, and pay for them later (but at least you still have your job).

The point is as simple as this: Given any starting point, there is a critical instant in the future, from which point on you will begin suffering from having seriously hampered your productivity by having ignored "research" (really a buzzword for just taking the time to reduce your technical debt or avoid it all along). Accordingly, of course, while you are ignoring "research", you will be getting more work done for a while, but this period is not everlasting. This fact is represented by the orange-y striped area in the chart above.

No matter how hard one may bang their head on a wall, there is no getting around this fact. Technical debt accumulates interest. A problem that takes x hours to fix now, takes y >= x hours to fix later, with the ">" being far more probable and the difference growing with time.

All there is to do, then, is to make serious considerations, whether this critical time in the future is closer, or not, than some extremely important deadline. If you are going to handicap your future productivity, you must have very good rea$on$ to do so! Think something along the lines of an all-or-nothing deal, for example.

Keep in mind that ignoring research may, at times, be the "wise" thing to do. For example, your company may be in need of resources, which are expected to come before t-critical, but definitely not later. So, painful catching-up is often better than no company at all.

This is the hard stuff the managers have to handle, of course, so it's their call, but they need to understand the facts very well. Maybe if you gave it a little thought, you could approximate some actual numbers in there and discuss with your manager using these numbers about how you are beyond this critical instant in time and you are constantly preparing for ever lowering productivity rates.

If your manager takes time to, at least, pay attention to what you say/show, some catchy chart might get the point along far better than any amount of spoken words.

Update

Due to some of the comments raising new questions, it needs to be stated that the chart above is just a(n overly) simplistic approximation. Estimating the approximate location of this t-critical instant is a very hard problem, but is not the problem we are usually trying to solve (this is, according to the single-responsibility principle, a problem of Management). What we should strive for is to know which side of the temporal axis we are at, with respect to this instant, at some given time.

Also, this chart simply represents what Management needs to know: "If we ignore investigation ****, research (and all other keywords, which are just aliases for proper code housekeeping), we will never become as good as we could have been if we just spent a little more time in the beginning". If one of the ambitions/goals/necessities for the company is a highly flexible and high-performance tech team, given the current codebase/product state, they might just as well drop it sooner instead of wasting more resources on a lost case.

Based on that, the dialog could be like this:

  • See this 1st line high above, "Peak productivity with research"? That is where we will probably never be even close to.
  • See this 2nd line below, "Peak productivity without research"? This is where we will be at best, that is, if we are lucky. Don't try to measure this in metric units, the vertical scale is shrunk by multiple orders of magnitude!
  • If the survival of the company depends on being "viably" above the lower line, we should simply call it off now that we can, to save resources, and start considering different career opportunities.
  • The way we are heading right now, we are past t-critical, so, in order to even be able to climb above the 2nd line at some point in the future, we need to work very hard to first repay the virtual work gains represented by the orange-line-striped area, and then strive to slowly translate the gained productivity benefits to an amount of work that is sizable enough to deliver.

  • Note that by "virtual work gains", I mean that doing more work then was like stealing that work from the future. Can you imagine how much better our life would be if we had an extra 10 minutes of productive time each day? Well, going to work in our underwear would offer us those 10 minutes of additional productivity. This is precisely what was done. Not dressing up is not a good way to save time from your work, I hope you follow the analogy and the metaphor.

  • By the way, it is not enough to be adequately productive, you also have to keep in mind the amount of work needed to be carried out have been carried out at any time. This is represented by deadlines! Either you move the next planned deadlines to get time for recovery, or we all go home...not now, of course, but a few deadlines from now, when catching a deadline will require productivity that is far above that 2nd line on the chart... the one that we will never reach if we keep going like that...

| improve this answer | |
  • 1
    On an "empty" code base with some experienced devs, you start almost immediately with a high productivity which then decreases over time the larger the code base gets. The picture should reflect that. – Doc Brown Nov 6 '19 at 5:29
  • A lot of two-bit startups will be bankrupt or sold-off by time you get to the "critical time". Most of their competitive advantage is to undermine the companies investing in long-term quality. – Steve Nov 6 '19 at 7:52
  • 1
    That graph looks very scientific, but I bet you just made it all up without any data, right? In particular you cannot predict when the critical point will happen, if at all, so you cannot really plan for it. – JacquesB Nov 6 '19 at 8:36
  • @JacquesB Yes, of course, this is just a very simplified illustration, not of all potential cases, but of two very specific cases. I will edit this into the answer. – Vector Zita Nov 6 '19 at 17:03
  • @DocBrown My point was not absolute productivity, but relative productivity. If you don't pay-off technical debt (this is what research **** alludes to in the picture, I borrowed that from the question) as you go, regardless of it being already there, or "newly inflicted", it accumulates interest. The more you ignore it, the closer you get to an instant in time, where you would be in absolute terms better off not having ignored the technical debt at all along the way. The consideration is, then, whether that instant and the circumstances are worth that definitive risk... – Vector Zita Nov 6 '19 at 17:18
1

With agile, the idea is to plan by doing, and clean as you go. When I have a week to plan a feature for a messy code base, the process goes something like this:

  • Spend a morning brainstorming rough ideas and whiteboarding with my colleagues.
  • Spend the afternoon trying to do the first step in the most promising idea. If it's new tech, that means some sort of hello world. I'm not really trying to accomplish the main task here. I'm trying to find out what will stop me from accomplishing the main task.
  • At this point I've often run face first into some badly structured code. I spend a day or two cleaning it up and improving tests, just in the area I'm going to directly need to change to add the feature.
  • Spend a morning trying to add the feature again. Hit a more fundamental roadblock and decide to pivot to plan B that I brainstormed on Monday.
  • Since the feature is in the same general area, the cleanup I did on Tuesday is still helpful, but the new approach requires some additional cleanup in a slightly different area. Spend the afternoon doing some more cleanup.
  • Now the code I need to change is in much better shape. I understand it more deeply. I've tried a couple different approaches. I can better explain to product management why certain approaches are infeasible. I can make much more rapid progress, with shorter cleanup/add code cycles.

Cleaning code as you go is how you move fast. Working in the code is how programmers learn what works. That doesn't mean you don't plan. It means you make your plan/execute/cleanup cycles on the order of hours instead of weeks.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.