Comment by temporallobe | Hacker News Reader

Comment by temporallobe | Hacker News Reader

Parent Full thread

My first software engineering job was with a big aerospace company about 20 years ago. Back then, budgets were big and the culture was completely different. Even the lowest peon had a huge cubicle with lots of desk space and privacy. Standups were not a thing and Agile wasn’t on the radar. We had lots of time to do anything we were assigned and never had to do much reporting aside from weekly meetings. We all had a general sense of schedule but it wasn’t rushed at all. We also didn’t have rhe always-in communication tools like Slack. Phone calls and face-to-face were it. This all made for a very relaxed environment where no one felt rushed and we had time and space to contemplate and concentrate. This is where I learned and created the most. I basically taught myself Perl, Unix (we had SPARC x-terms), Java, bash, csh, ksh, SQL, Javascript and web application development, and so much more, all of which I still remember to this day. I was happy and relaxed and pretty much always looked forward to learning and exploring more every day. Clearly this type of environment works well for some people, and it certainly did for me. I credit these early years to my success. Fast forward 20 years and I am in a completely different environment - open office plans that encourage collaboration but also distraction, Agile tools that promote micro-management down to the number of minutes you spend on a task, daily stand-ups (sometimes multiple per day if you’re involved in several projects), and constant reporting to management, SCRUM masters and POs. Oh and chat tools. These constant interruptions often make it impossible to truly do creative and deeply thoughtful work. Most of what I do is rushed and measured and we are always analyzing what we can more efficiently and quickly. Responsiveness to messages are also scrutinized. Oh and all the meetings - Sprint planning, retrospectives, reciews, backlog grooming, etc. I estimate that most of what I do these days is a lot of administrative busy work and useless overhead, which is definitely not conducive to doing what I believe I do best - write code.

Here is a counterpoint. I worked with software development at Ericsson for about 10 years before XP and agile came out. I too had a private office, and I recognize a lot of what you describe. While it was nice, it was not a very productive environment. Each release of new SW was enormous and typically took a year or more to get out. The developers had no real idea of how things worked in production. Lots of useless documentation was produced. Later on, RUP and tools like Rational Rose were introduced that made things worse. Basically, things worked out despite the process and tools, not thanks to them.

In all my jobs since, I have worked in a more agile setting. By that I mean that the team is small (less than 10 people) and sits together with some sort of product owner. Not private offices, but rooms where only people working on the same thing sit. Frequent releases, fast feedback. Very few meetings, most issues can be worked out in the team. In my view, this is a quiet environment, but occasionally there are dicsussions that you overhear (but that is not a problem). In these types of environments I have been much more productive than I was at Ericsson.

What you describe looks how agile was supposed to be. What the op described looks like a perversion of agile perpetrated by managers who either don't understand why agile was born, or do understand it, but only care about increasing their power instead of getting things done.

I know. When I first read the XP book by Kent Beck it was a revelation. That was the first time I saw a methodology that I felt worked and agreed with my own experience. Planning everything out in advance is hopeless.

There are two great quotes that I think capture this:

“A complex system that works is invariably found to have evolved from a simple system that worked.” John Gall

“Enlightened trial and error outperforms the planning of flawless intellects.” David Kelley

It is really sad to read about how often the agile ideas have been misused!

How about "a team of skilled developers is likely to be successful with any software development approach; an inexperienced or untalented team is doomed regardless of the chosen methodology"

After 20 years that's been my experience

Yes. But unfortunately not every team can be made entirely of rockstars. So the purpose of a methodology is to increase the probability of success for a moderately talented team.

Between you and what OP is saying, I think there is this something thing else also. Core software development activity (UI, databases, messaging, web servers, configuring legacy systems, testing, release and delivery, etc) is helped by people sitting together on an agile track. However for some software development this also means architecting the product itself, an aspect that is crucial to a company's survival too. In a company building a demand management product, I need to learn and understand the market, consumers, sales processes, our internal systems that manged these before drafting the demand models, fine tune the methodology, etc before anyone really build the software product/services that reach the end-user. And there is a cycling back and forth between the two activities as we move ahead to get things right. I had no product manager or analyst who could really help with the product itself that the company wants. This latter part is where where I have a very hard time sitting in an open space with 10 people talking on the phone or getting pulled into frequent meetings.

I have no doubt you're right.

The thing is, you can have development standards that require small iterations that are immediately deployable and this are immediately tested and deployed, without pulling all the overhead of some PMs interpretation of scrum.

I often find the power is generally with the wrong people and they promote the things that matter to them at the detriment of everything else.

I don't personally believe this is by design, it's just people in $foo management position tend to have the soft skills to make their job easier, when many of the developers often don't. And managers, who tend to control budgets and define departments, tend to give those departments to more managers and there's not a lot of people in the room telling them that a software person should probably run a software team.

Have you asked people who work at Ericsson today? From what I have heard it is hard to think that things are better today despite moving to things like agile.

I work at Ericsson today. Unfortunately, the environment is very much like the one described by the OP: open plan office, noise, chit-chat, interruptions, daily stand-ups (which are mostly a waste of time), scrum meetings which take place far too often, retrospectives which turn into blamestorm sessions. All of this makes the office a rather unpleasant place to be. Which is a shame, because whenever I get to actually sit down and get some work done, I tend to enjoy it.

You'd think I could cope with this by working from home, but that option is limited, too.

I keep reading about how scrum,agile,openspace,slack,oncall,whatsup outside of work has ruined developers productivity and life after work.

WHY dont we do something about it? why are we going like cattle to the slaughter house? We are developers right we are supposed to be smart, intelligent yes, we have let this come all over us step by step until we have lost our life.

Developers - it's time to raise to the basic work environment, we need space, we need to do our work with focus, and YES we need separation between work and home.

If a company needs work-after-work they should hire people for these after-work hours, if messages are sent after work, and it's just this additional answer this mail, it should either be handled by workers who work over these hours or just wait to tomorrow

We have let this on us, and it's our duty to bring back the focused work environment and the joyful home environment without interruptions from work or being oncall or answering messages.

Companies would rather hire less-talented, less-perceptive, less-skilled workers if they will express fealty to mandated bureaucratic marching orders, even if it means paying more money, letting projects fail, losing business, etc.

Companies _will not_ negotiate things like letting developers have autonomy over the process by which the work is managed and delivered, or letting developers have private offices.

This is just standard Moral Mazes 101 stuff. Preserving the property that employees behave like obedient dogs instead of free thinkers is the absolute number one mandate, to the detriment of all else.

Just man up don’t answer messages off work and don’t make a fuss about it.

Since taking a new developer job about a year ago I made a commitment to not sign into my work email on my phone and it's been great.

But yeah, what the other commenter said. Just do it!

I’ve recently started a job where my time isn’t measured. My time was measure 2012 until 2018. 3 different jobs. Utter misery. Now I’m having a lot more fun and feel very productive in the true sense of the word. There is still stand ups and slack etc. but I don’t mind that so much. Having a stopwatch constantly ticking against you is the main hell I hate in modern tech culture.

Did you have time budgets or quotas? I’m curious how these companies used the measured time, what made it feel so oppressive. (I have no doubt it feels oppressive, just interested in the details.)

When I’ve done contract work, and when I ran a startup, I started tracking my own time. I find it helps me focus and account for my time and understand my own habits. It’s not very good for open problems or exploratory work, other than to find that they take a lot of time. ;)

Other than tracking myself, I’ve never had a job that measured my time directly. I had one job that did measure when employees were at work, but they didn’t show it to employees nor set any quotas, they just wanted to understand work patterns.

It’s more of a case of being dragged into a room to discuss why task X and take Y took 6 hours instreas of 2, or 4 weeks instead of $what-manager-coulda-dunnit-back-in-the-day. At those companies I had to let a lot of shit go through code reviews and take shortcuts. That stuff wasn’t measured.

Ah, thank you. Sounds not very fun. May your new company celebrate goals accomplished in years rather than worry about tasks not accomplished in hours.

Were you working for Crossover or similar?

(not OP) it seems to me it is now "normal" for remote companies to track every second; is it really as soulcrushing as it sounds? Do you have any real world experience with crossover? (I am seriously considering applying with them)

Isn’t Crossover a scam of some sort?

Nope not worked for any famous companies.

This reminds me also of my most productive days. Funny how enough people create their own middle management jobs, and jobs like "scrum master", that literally seek to destroy developer time.

If your Scrum Master is destroying developer time, then s/he is "doing it wrong".

The main function of the Scrum Master is to shield the developers from all the non-development crap. I've worked with one guy who was so good at it he would play interference and defend us from outside interruptions almost literally (actually blocking people from coming to our desks, making sure we could focus, holding meetings only if someone on the team expressed some kind of blocking issue that he couldn't solve by himself, etc)

Sure, probably this was more about him being a good manager than the "process" behind it. But no matter the process, if a manager is destroying productive time from the developers the fault is in the individual, not the environment or process adopted.

> But no matter the process, if a manager is destroying productive time from the developers the fault is in the individual, not the environment or process adopted.

Why can't it be both? Bad managers can be empowered by a process, just as good managers could be hampered – no?

Agile provides so many tools for bad managers to micro manage, so that even if the process itself is well intended it still could lead to hell – no?

One of the tenets from Agile is "People before Process". Bad managers will micromanage no matter what processes or tools they have at hand.

So, no. Bad managers should not be empowered by Agile. They should be weeded out, by other people first and, failing that, results second.

> Sure, probably this was more about him being a good manager than the "process" behind it.

Of course also that, but you're completely right that that is the exact job of the Scrum Master. To "remove impediments". No matter if the impediment is some process or a manager, it's the Scrum Master's job to remove it.

This actually aligns pretty well with the ideas in Agile Manifesto. And that's why I'm so sad when "scrum master" nowadays mostly seems to mean someone who counts the minutes devs spend on each Jira ticket, and haunt the team when velocity seems to be dropping 10% for the second day in a row.

jobs like "scrum master", that literally seek to destroy developer time.

We can’t really ever hope to make progress with improving productivity or work environments if people contribute to be this reductive.

A “scrum master” role does obviously not “literally seek to destroy developer time” - it’s a patently ludicrous assumption. But if you are in a situation where this is happening - rather, where a “scrum master” role is getting in the way of work - then it does point to something else going wrong in your organisation.

So, I didn't mean to offend anyone, only speaking from my experience.

I feel most jobs, at some companies in some situations, are absolutely justified. The problem is that then every company thinks they need to follow suit, and it ends up being a giant time sink. I'd wager most scrum masters are viewed by their team as a net negative (my opinion). But of course no person whose job acts as a hindrance will admit as much.

Fwiw: I believe it should be “I credit my success to these early years”.

Reply on news.ycombinator.com