Hacker News Reader

Comment by crankylinuxuser | Hacker News Reader

I'm a sysad in a software business.

Sure, the professional developers are paid well. However the more Jira and agile ideas takes over, you become more replaceable. Why? You're just a card-filling machine dealing with feature requests or problem reports.

And sure, the next developer may fill less cards, but they will improve with time.

And if you don't work in a protected area (federal, etc), then you can buy card-filling devs for 1/5 to 1/8 of US... And have them QA'ed for less than 1 USA dev.

Face it: I, a sysad, am a service worker. And devs are line workers. We're well paid, but so were factory workers at one time.

View on HN

I disagree with this completely. Development is not line work, and doing it like line work creates unmaintainable, expensive crap. "The Mythical Man-Month" explains this well. Conceptual coherence is of the utmost importance in effective software systems, and you don't get that by just knocking out stories one-by-one like they're desktop support tickets.

People like us who spend their free time on a message board about programming know it's best not done as line work. But the general population doesn't, and probably many developers don't.

There is constant, never-ending pressure to turn it into line work and we need to be aware of it. A lot of software running (barely) in the real world is written this way.

While I agree with you, it's also true that the majority of software in the world is held together with bubble gum and duck tape. That doesn't mean it should not have been written - it solved some problem for someone.

We should not build complex systems that way, but plenty of systems are not very complex.

Updating strings in database/code is line work. Update images on website is line work. Debugging basic issues is line work. I've gotten these tasks as discreet Jira issues, so someone thought it was important enough.

It's fine if line work + hardcore CS positions exist simultaneously. This fighting over the boundaries of where the profession starts and ends is tiring and we should just accept there's a stratification of developer skill levels and start adjusting our attitudes and training accordingly. Development is all of these things because development is a huge job market.

You can't abstract your way out of doing the line work and only have hardcore CS positions in the job market.

> Development is not line work, and doing it like line work creates unmaintainable, expensive crap.

Huh, it is already happening. I see everyday so many web services are created via auto generating scaffolding tools like Spring boot etc. One just fill in environment details, bits of JSON parsing and service is ready to be deployed.

Good for you that where you work people are intelligent enough to read Fred Brooks. Most places, including the ones with fancy gleaming buildings, open office floors, lounges with couches and organic smoothie bars are just making CRUD services with some cloud backed data storage. More so terminology I see at work is more inspired by factory floor not some intellectual venture.

Great, looks like you have discovered "That one trick that all engineers hate!"

If all it took was some scafolding, some database columns and some html and sprinkle, you should be a millionare by now?

Well I am arguing it is all 'factory' work. And factory workers do not become millionaires. Are you saying they do?

You have not operated where software defines the industry, but where it is a third tier service to the industry.

You can’t write software in a vacuum.

To write good code, you need to understand the whole program (or at least a very substantial part of it), why certain decisions were made in the past, the potential ripple effects of a “simple” change, etc.

This means that it’s impossible to just swap devs out like factory line workers, otherwise you’re just creating more bugs.

For similar reasons, you can’t paint half a canvas and then hand it over to another painter and have him finish it...

Your scenario perfectly describes practically all code I come across in the wild (I work outside of a tech center).

Who writes the cards?

It's easy to write them, but writing the right ones is much harder. Automate or outsource that and you become a trillionaire. Yes, seriously.

> Sure, the professional developers are paid well. However the more Jira and agile ideas takes over, you become more replaceable. Why? You're just a card-filling machine dealing with feature requests or problem reports.

Agile do not make developer replaceable. If anything it empower developers to become on equal footing with everyone else.

> And sure, the next developer may fill less cards, but they will improve with time.

I saw projects outsourced to huge teams in India failing to deliver. Reality of software development is that unless you have right mix of experience, skill and people you might never deliver.

Programming require both engineering and creative skills. Some class of problems cannot be brute forced by large number of young bodies.

Agile shouldn't make developers more replaceable, but in my experience that's the effect of Scrum when wielded by many kinds of management. Stuff like "story points" rigged such that a problem that would take a week must be reduced to smaller--preferably parallelizable--micro-stories that have implicit context but no explicit dependencies so that the decision of farming it out to many juniors can be upheld.

I'm not saying that this actually works better, to be clear. But I would bet it works cheaper for the time horizons that the folks making those decisions care about.

Splitting the store into smaller tasks is better. It forces you to plan and communicate your progress. It allows for adjustments in both requirements and estimation. In many business cases, this approach is better. The senior developer should outperform multiple juniors anyway, in most cases, it is seniors that carry progress.

Toxic companies will twist a good process and make it horrible. It is not Agile or Scrum to blame.

Splitting things is not inherently bad.

Doing so in an attempt to commodify its application is not inherently bad.

Doing so in an attempt to commodify its application is definitely bad for developers' careers.

If you care more about career than team success, project delivery and skills progression you are already in a sad place.

"Commodify of application" is a good thing. This means that your team is flexible and can adapt to changes. It mean that there little of key person dependencies. It makes you go for holidays without worrying that your team will be able to finish a new service because you are one of two people that can navigate AWS :P

There will always be software development work that can’t be done that way because it requires specialized knowledge or cutting edge programming techniques.

Yes, like making handmade clothing, only certain cases require advanced skills like that. I think over time less and less work will require that handmade software. More can be done by putting other packages together. I've been luck to work on infrastructure work that has ended up having new ideas and advancements over existing systems that we could justify a new version. But I do feel like this opportunity to do new stuff could shrink. How many compilers, databases, os kernel writers do we need? The vast majority of people can make great use of an existing compiler, or database. Justifying making a new one should be hard.

Thats a funny way to look at it - if anything a sysadmin is more of a line worker (I do both dev and sysadmin so I'm not particularly invested in either), with enough software you could be replaced by BA's coming up with architecture requirements and a system like docker...

Just a perspective thing I wonder

Peculairly enough, ive had our management ask how to show what we do, and how we allocate out time. And as many times we have ticket after ticket from Jira, nothing adequately shows how we work.

That's why I equated Sysads as service workers. Some assistance may be 5m, and others may have looked like a 10m issue but turns into 3h timesink. We're serving others, or serving machines for serving others.

Whereas I see Agile, or the Kanban system, to be set up to send work to either internal or external devs. The only reason why real factories don't use international work is because sending lines and parts is onerous on a short cycle... Whereas software Kanban seems fit for each other.

Sure there's dev work that requires specialty knowledge, but most dev work is a CRUD web app with a DB backend. And those jobs are especially prone to outsourced via a thousand cuts.

Reply on news.ycombinator.com