Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why are you so busy?

tomlingham.com

Post reply on HN
Print view View original

61–70 of 130 posts

Re: Why are you so busy?

#61

Post by KronisLV »

nstart wrote: post #56
jiggawatts wrote: post #39

Please note the important caveat in the article: If the following are true: Your team is following software engineering practices that have been shown time and time again to be indicative of highly performing technology teams (think CI/CD and DevOps). This is all too often the root cause of developers being "too busy". I've had some variation of the following conversation nearly verbatim with six different teams in t…

While this example feels pretty obvious, I think in practice, these conversations conflict with the third caveat mentioned: "Your team is always working on the next most important thing (as prioritised by the business)" When the business functionality and marketing needs compete with technical advances, there's a decent amount of negotiation that needs to be done and that negotiation varies wildly from company to com…

> When the business functionality and marketing needs compete with technical advances, there's a decent amount of negotiation that needs to be done and that negotiation varies wildly from company to company.

I think that this is the crux of the problem, but the solution lies elsewhere rather than just in negotiations.

After all, if you plead for some time to address technical debt and do platform improvements, you might just get told "no" to, given that in certain cultures people won't view these things as something that generates value directly and convincing them otherwise will be an uphill battle.

So why not just announce that X% of the following sprint or month will be spent on these things, to ensure successful continued operations? That's about the same as writing tests instead of having bad coverage due to an ever growing backlog and scope creep which eat up all your time.

After all, you don't ask business about using a version control system, do you? You just go ahead and do what's necessary to version your project. Tests, CI/CD, configuration automation etc. should be treated the same, since we're paid to be engineers and a part of that engineering is ensuring at least decent quality.

Note: this probably doesn't apply to larger efforts, like changing the entire architecture of your application etc.

Re: Why are you so busy?

#62

Post by imtringued »

kqr wrote: post #60
jiggawatts wrote: post #39

Please note the important caveat in the article: If the following are true: Your team is following software engineering practices that have been shown time and time again to be indicative of highly performing technology teams (think CI/CD and DevOps). This is all too often the root cause of developers being "too busy". I've had some variation of the following conversation nearly verbatim with six different teams in t…

There's also the more insidious version of this where instead they go, "That sounds nice, but we really don't need it." "May I ask why you don't need it?" "Oh, we found that we spent so much time on deployments that we decided to do only one planned deployment per year now." In this case, the people you're talking to have obviously only swept the dirt under the rug, but sometimes they honestly think they've solved th…

I always thought this was strange. A lot of our deployments don't take time to actually do, they mostly take time to decide when the next deployment is and what should be included. If I could deploy as fast as possible I think I would end up spending less time.

Re: Why are you so busy?

#63

Post by [deleted] »

jiggawatts wrote: post #39

Please note the important caveat in the article: If the following are true: Your team is following software engineering practices that have been shown time and time again to be indicative of highly performing technology teams (think CI/CD and DevOps). This is all too often the root cause of developers being "too busy". I've had some variation of the following conversation nearly verbatim with six different teams in t…

[deleted]

Re: Why are you so busy?

#64

Post by tjlingham »

whaaswijk wrote: post #10
RyanOD wrote: post #4

I turned this into a poster and hung it in front of my desk. Great quote. “as long as you are doing your work well and continuously working on the next most important thing prioritised by the business, any pressure to deliver beyond what your team is capable of is objectively unreasonable.“

I think the “doing your work well” part is often the question. Am I really doing all I can? Could I do better/more? This then leads to working more and being busier. Maybe the problem is that it’s hard (for some of us) to know what “well” really means.

This is one reason why I go all in on practices that are backed by data to correlate with business success (CI/CD, DevOps, etc.). Think the Accelerate book. Software development has the added difficulty of being quite a young industry (relatively speaking), but (with tongue in cheek) how can you be expected to do better than practices espoused by industry leading research and companies?

Re: Why are you so busy?

#66

Post by zo1 »

christophilus wrote: post #44
jiggawatts wrote: post #39

Please note the important caveat in the article: If the following are true: Your team is following software engineering practices that have been shown time and time again to be indicative of highly performing technology teams (think CI/CD and DevOps). This is all too often the root cause of developers being "too busy". I've had some variation of the following conversation nearly verbatim with six different teams in t…

When I started at Microsoft, this exact scenario happened. I was told I couldn’t automate things because there was no time. I did it anyway, and a 3 person job suddenly became an extremely part time job for one person. It blew my mind that anyone at Microsoft, of all places would have this mindset.

Because it worked out for you, that time. As a manager and probably the person that would have told you no, or to justify more before we attempt it, I've seen this scenario go pear-shaped way more times than not. It's about risk, priorities, and specifically knowledge/experience (sometimes wrong) that says this is "not a good idea". Sometimes it's also just plain old complacency, though.

Re: Why are you so busy?

#67

Post by leghifla »

bena wrote: post #46
jiggawatts wrote: post #39

Please note the important caveat in the article: If the following are true: Your team is following software engineering practices that have been shown time and time again to be indicative of highly performing technology teams (think CI/CD and DevOps). This is all too often the root cause of developers being "too busy". I've had some variation of the following conversation nearly verbatim with six different teams in t…

I feel both sides of this one. Yes, creating automated processes would make things easier, but the time it would take to automate the process would take too much time before you have to deliver. So everyone knows what needs to be done, everyone recognizes that it would help things, but no one can put down what they're juggling to handle it. Sometimes it takes bringing on a person just to take on that project as its o…

Regarding a dedicated person to handle the CI, here is my experience.

In the small company I am working now, I had setup a adhoc deployment script that was working fine, took less than 5min (with no user interaction) on my dev PC. Since it is not a SaaS, our release cycle was a bit slower than wanted, 1 or 2 times per month, depending on circumstances.

A guy was hired and he wanted to speed this up. I explained clearly that the build/deploy script was not the cullprit of the "slow" release cycle. It takes time to decide was is ready for production, write a nice changelog for users (not just collecting git messages), testing on the custom hardware...

That is why it took me an hour to half a day when the boss said: we need a release today. The above guy was justifying its work by: "After I am done, you will just need to put a tag and the rest will be automatic". I could not convince my boss this was fantasy land.

Result 3 years later: we have a "nice" CI which rebuild the world several times per day. But we are doing maximum 2 official releases per year, with much more stress. We had a few "releases" which needed very urgent hot-fixes because of last-minute changes and not enough testing on hardware.

And the CI person is constantly tweaking bits of the CI (it has become part of his job), breaking thing here and there.

I long for the old days...

Re: Why are you so busy?

#68

Post by kqr »

imtringued wrote: post #62
kqr wrote: post #60

Earlier quoted context omitted.

There's also the more insidious version of this where instead they go, "That sounds nice, but we really don't need it." "May I ask why you don't need it?" "Oh, we found that we spent so much time on deployments that we decided to do only one planned deployment per year now." In this case, the people you're talking to have obviously only swept the dirt under the rug, but sometimes they honestly think they've solved th…

I always thought this was strange. A lot of our deployments don't take time to actually do, they mostly take time to decide when the next deployment is and what should be included. If I could deploy as fast as possible I think I would end up spending less time.

I'm not sure what you mean. If you have the luxury of deployments not taking time, then why do you need to debate what to include? Just deploy as soon as anything is ready for deployment.

Re: Why are you so busy?

#69

Post by nstart »

KronisLV wrote: post #61
nstart wrote: post #56

Earlier quoted context omitted.

While this example feels pretty obvious, I think in practice, these conversations conflict with the third caveat mentioned: "Your team is always working on the next most important thing (as prioritised by the business)" When the business functionality and marketing needs compete with technical advances, there's a decent amount of negotiation that needs to be done and that negotiation varies wildly from company to com…

> When the business functionality and marketing needs compete with technical advances, there's a decent amount of negotiation that needs to be done and that negotiation varies wildly from company to company. I think that this is the crux of the problem, but the solution lies elsewhere rather than just in negotiations. After all, if you plead for some time to address technical debt and do platform improvements, you mi…

I agree with the idea that solutions can lie in more than just negotiations. But I will also say that I’m at the point in my life[1] where I believe the vast majority of solutions do lie almost purely in some form of negotiation.

Take your own example:

> After all, if you plead for some time to address technical debt and do platform improvements, you might just get told "no" to, given that in certain cultures people won't view these things as something that generates value directly and convincing them otherwise will be an uphill battle.

This right here is a negotiation between business and engineering. The business unit cares about technical debt only if it affects successful delivery of business goals. As such it needs to be negotiated along those lines. In fact, I’d say you make a wonderful negotiation right after:

> So why not just announce that X% of the following sprint or month will be spent on these things, to ensure successful continued operations?

That is an excellent negotiation right there. The business cares about successful continued operations. Stopping everything to focus entirely on technical debt is not successful to the business. Allocating x% time to a mutually beneficial goal where x can be continuously tweaked is an acceptable point.

> After all, you don't ask business about using a version control system, do you? You just go ahead and do what's necessary to version your project.

The thing about this point is that it is:

A) easy to get setup.

B) well understood enough now to know the benefits to the organization

I’d argue that ci/cd is coming closer to that point now. Definitely is on the right trajectory and for the same reasons. Easy to setup and the benefits are well known and easily understood.

More nebulous topics like testing and tech debt will for the foreseeable future be topics requiring decent negotiation.

[1] I may change my mind on this in the future. Definitely been around on topics where I believe one thing, believe an alternate point of view, and later have a softer or accepting view of the original idea :).

Re: Why are you so busy?

#70

Post by lifeisstillgood »

tjlingham wrote: post #50
conradev wrote: post #47

While I love this quote: > as long as you are doing your work well and continuously working on the next most important thing prioritised by the business, any pressure to deliver beyond what your team is capable of is objectively unreasonable. I feel like this is missing an acknowledgement that "what a team is capable of" actually depends on the manager! Managing people and priorities takes skills that require practic…

I couldn't agree more. This is written from the perspective of a manager so I am likely asking a bit too much from the reader to make the connection. Thank you for the feedback! My experience tends to be that managers will rarely get help to manage the teams WIP and it's often left to that same manager to provide that mechanism of back-pressure. But if they then don't, for whatever reason, then it can be bad news for…

Surely then all that should matter is reviewing the code and reviewing the WIP (jira). for each manager each day

doing anything else is pretending project managers are managers

Post reply on HN