[HN Gopher] Software engineering salaries come from one of three...
___________________________________________________________________
Software engineering salaries come from one of three budgets
Author : serialx
Score : 464 points
Date : 2024-01-03 05:25 UTC (1 days ago)
(HTM) web link (swizec.com)
(TXT) w3m dump (swizec.com)
| dbetteridge wrote:
| Background is completely white and text unreadable, toggling
| 'modes' fixes this but I presume its related to OSX and
| dark/light mode.
|
| Chrome Version 120.0.6099.109 (Official Build) (arm64)
| mooreds wrote:
| In addition to knowing which bucket your salary comes from, I
| think it is also useful to know how your organization values
| building software. Because this affects your career just as much.
|
| * Is your company selling software development hours
| (consulting)? I'm this car you'll be valued for client relations
| skills and the ability to bang out acceptable software.
|
| * Is your company selling a software product (product company)?
| In this case you'll be valued for your ability to build and run
| software.
|
| * Is your company selling something else that has a software
| component or that software enables (pretty much every other
| company)? In this case, you'll be valued for your ability to
| deliver on or below budget and you'll never be the star of the
| show.
|
| Funnily enough, these seem to map well to the three categories
| the author mentioned. Consulting to sales/marketing, product to
| research and development, everyone else to maintenance.
| zerr wrote:
| > * Is your company selling a software product (product
| company)
|
| In the B2B world it is common to have a complex enough product
| that needs training services and tech support as well. Some
| vendors also add exams/certifications on top of it.
| mooreds wrote:
| That's fair, I was painting with a broad brush.
|
| Once you get to a certain size of consulting company, you may
| also have an r&d department or someone responsible for
| building common libraries or knowledge repositories, for
| example.
| Scarblac wrote:
| Or a combination. I'm in a pretty small company (about 80
| people total, 15 devs) and worked on all three of those last
| year.
| mooreds wrote:
| I'm a bit confused. You worked as a consultant selling hours,
| one a software product sold for a price and also on an
| internal enablement tool for the same company?
| jaymzcampbell wrote:
| Not the OP but I can believe it - where I work the main
| business is consultancy style work but to support that work
| there's custom generic software developed to sell/license
| to clients as part of a value add and there's dozens of
| internal tooling to support delivery teams. We have
| developers that will move between all 3 of those areas
| depending on their current allocation to client work.
| mooreds wrote:
| Sounds awesome! Thanks for illuminating me. How are these
| different work streams prioritized?
|
| At first glance seems like the last category would suffer
| unless someone was "on the bench".
| michaelt wrote:
| Scarblac's mentions a company that only has 15
| developers. That means time spent on internal tooling
| like, say, improving the CI system has direct benefits
| for the other 14 developers, all of whom probably report
| to the same boss.
| IggleSniggle wrote:
| In a smaller company it's not hard for "invisible" (like
| CI) contributions to be actually seen and noticed by both
| leadership and by the people you work with every day. And
| on the other hand, if you're a dev working on product and
| getting work done is a lot harder than it should be,
| you've got a strong incentive to pause product work and
| focus on "maintenance" work.
|
| When almost a quarter of the company (15 devs) can both
| see and feel your contribution to make their lives easier
| and more productive, you've got a pretty strong political
| position even if you aren't directly producing product.
| This is true even if you produce, say, an internal
| dashboard: you're known as the one dev who took time out
| to help the 20 sales people sell better (or whatever);
| you know their names, and they know yours.
| jaymzcampbell wrote:
| We have a process whereby people can request a change
| after a certain period (and team permitting) to allow
| people to rotate amongst different clients and different
| work streams. I think it's usually after 6 months on one
| particular thing you are eligible to request
| reassignment. Won't always be approved ofc.
| 9dev wrote:
| I've done this myself, too. We were building a WhatsApp-
| based support ticket system, that was the product; for
| large customers, we'd build chat bots (glorified decision
| trees) on hourly billing; and internally, we'd have an
| integrated CRM system and messaging API that other systems
| would rely on. Over the course of two years, I worked on
| all three.
| sumtechguy wrote:
| Some consulting companies also have software they sell as
| well as internal things that need to be done. They can have
| a 'boxed software' that gets 90% of their customers. Then
| consulting on top for the customers that do not want to do
| anything themselves or something the boxed software doesn't
| do. Plus you have internal r&d projects or other things.
| Scarblac wrote:
| Yes. About 40 of us are water managent consultants, I write
| tools for them to use in their projects (based on our
| products). Also sometimes we do projects where we write
| custom (water management related) software for customers,
| as consultants. And we have a few products of our own,
| mulyi tenant web apps, that similar customers buy licenses
| for, that I also work on.
| verinus wrote:
| this.
|
| first company is good for starters to get to know others.
|
| third should be avoided if you want to stay in software and not
| transition to management. You will always be seen as a
| necessary evil, your problems not understood while others
| working on core products will be perceived as an asset.
|
| second one is the one to make a career in software dev.
| resonious wrote:
| I actually had a pretty good time at a third-category place.
| When you're writing software for a non-tech company, it means
| your customers are very close - often in the same building,
| working at the same time. You can watch them use the
| software, hear complaints in real time, and push solutions
| very fast.
|
| In my case, I might've been lucky, though. One of the co-
| founders had a CS degree and deeply valued the productivity
| boost we got from custom software.
| verinus wrote:
| ofc individual experiences might differ! it certainly
| depends on the company and leadership. From my experience
| in a bigger one understanding ended when leadership was
| needed in software areas, but leadership was recruited only
| from the other domain...
| rprospero wrote:
| Along those lines, one of the most toxic places I've ever
| encountered for developers was at a company that sold b2b
| software. You would think that developers would be valued
| for creating the product, but they were fully treated as a
| cost centre. The profit centre was the sales team who went
| out and got companies to send money. The developers merely
| existed because legal said that, for compliance reasons,
| the firm was required to provide the costumers with
| software after the client paid for said software (legal
| accounted for 24% of the company's budget while software
| development was 15%). If the sales team promised something
| that the software couldn't do (e.g. track the position of
| any cell phone in the country with just a phone number in
| the early 90's before smart phones), then any refund owed
| to the client would come out of the product team's budget.
| The salesman (they were all men) would not be required to
| return his commission, since he _did_ his job and got
| someone to sign a cheque.
|
| Surprisingly enough, the company was _not_ Oracle.
| makk wrote:
| > In my case, I might've been lucky, though. One of the co-
| founders had a CS degree and deeply valued the productivity
| boost we got from custom software.
|
| This. A mentor told me, "[As a software developer], never
| work for a company with a CEO who has never pushed code to
| production."
|
| I think you miss some good places to work by following that
| advice, but you avoid a ton that are worth avoiding.
| ttymck wrote:
| > second one is the one to make a career in software dev.
|
| Your comment and a dozen others make this out to be so black
| and white. If this is true then why am I finding it so
| difficult to make a career out of these situations. I find it
| impossible to identify companies in this category that are
| good to work for. Does anyone have any heuristics, or should
| I keep bouncing from one to the next until I get lucky?
| granshaw wrote:
| Just look for "good WLB" in the Glassdoor/blind reviews,
| AND that the company is healthy (doesn't need to be a
| rocket ship) business wise
| michael_leachim wrote:
| What category is Amazon? (the marketplace). It looks like a
| third category (company sells something else, but it has a
| software component supporting it).
|
| I am asking because I am working in a company with similar
| business model and I am trying to figure out what category does
| my work belong to.
|
| thank you.
|
| EDIT: fix msg
| strikelaserclaw wrote:
| I think there is nuance here, even within a product company,
| not all software is equal. There's software to support core
| business (think ads in Google) and there's probably software
| to support internal dashboards (also in Google), I'm sure
| engineers working in ads in Google have much more leverage
| than those working in making dashboards for ops or some
| internal ticketing system. Conversely, I'm sure the companies
| we traditionally think software is just needed to support the
| core business also have software lines which generate income
| or is critical to their core business.
| michael_leachim wrote:
| thank you, maybe it is easier to understand
|
| when you ask whether business will halt and die if the
| system you are responsible for is down or suddenly absent
|
| or
|
| it is going to be a mild inconvenience.
|
| I think, defined like this makes it less ambiguous
|
| edit: fix msg
| mooreds wrote:
| > when you ask whether business will halt and die if the
| system you are responsible for is down or suddenly absent
|
| This is a great way to put it.
|
| I also ask myself the question: "who are the rockstars"
| at a company. The folks that are celebrated.
|
| If it isn't a developer/engineer, you aren't at a
| category 2 company.
| michael_leachim wrote:
| thank you, I've got something to think about.
| jimbokun wrote:
| Over the years, Amazon has gone more and more in the
| direction of the software being the product.
|
| As an immense e-commerce site, the software enabling all the
| sales was the key differentiator to the competition.
|
| Then they brought in external sellers, making the e-commerce
| platform more directly a product.
|
| Then of course they started selling the infrastructure
| directly as a product, as AWS. Which of course relies on
| software to automate the provisioning, operation, and
| monitoring of those computing resources.
| michael_leachim wrote:
| thank you, so it more dependent not on a type of company
| but on how the company runs itself.
|
| It can have its main product not in software, but it can
| bet on R&D in order to outrun their competition.
|
| And the other way around is true too, that is how you get
| bad software products which somehow always stays afloat
| because of exclusive focus on sales.
|
| I agree that AWS is indeed a software product, this one is
| obvious.
| chadash wrote:
| Amazon is unique. If you look at their revenue, the vast
| majority comes from E-Commerce. But if you look at their
| profits, the majority comes from AWS.
|
| AWS is indisputably a software org, so it's clear that their
| senior leaders value software engineering. But I think that
| even Amazon's marketplace _sees itself_ as a software org.
| From the early days, they always saw software as being a
| competitive advantage.
| michael_leachim wrote:
| I agree that AWS is a software org, I am interested in
| E-Commerce in this particular case. Thank you for response
| hooverd wrote:
| You can definitely tell the difference in priorities for
| end users between Amazon.com and AWS too.
| ted6767 wrote:
| Amazon is a partial monopoly so it depends on where you're
| working. Your team could be any of the 3 areas mentioned
| under the same umbrella.
|
| Honestly a good manager will do more for your job than
| anything else.
| nonameiguess wrote:
| These categories are nowhere as cut and dry as HN seems to
| often think. Netflix is an even better example than Amazon.
| Infrastructure and delivery is certainly somewhat of a
| competitive advantage, but their product is not software at
| all. They're a media company, a production studio, a
| distributor. People like Shonda Rhimes are the true
| superstars and they get $500 million contracts that reflect
| that. It doesn't mean you can't have an extremely rewarding,
| well-compensated career as an engineer there, but you're
| still not Chris Hemsworth. You're not what their users really
| care about. Without content, there is nothing to sell, no
| matter how strong the software is.
|
| Then you have something like a Raytheon. They're a far purer
| "technology" company than any FAANG other than Apple.
| Hardware and software is literally all they sell. No ads, no
| media, no communities. But very few of the products made
| there are owned by the company. They're made on behalf of
| third-party buyers, usually the US military, which puts you
| in category 3 according to this kind of breakdown, but that
| is extremely misleading. You're not a cost center. The pay
| tends to be lower compared to silicon valley standards
| because of government acquisition laws and the huge number of
| hiring constraints that have nothing to do with technical
| excellence, but you're still the primary value creator and
| the military program you're working for will treat you that
| way. This one is arguably even weirder because the actual
| "product" of the military is war and the superstars are the
| soldiers, pilots, line officers. Technology developers are
| always in a support role, but that isn't any different from
| working for Apple or Microsoft. Whoever is actually using
| those products isn't deriving value simply from using a
| computer. They're doing real world work with it and that work
| is what they really care about. Technology is always an
| enabler. Nonetheless, technology developers for the military
| make a lot more money and have far easier jobs than even a
| four-star general, so which role do you really want?
| michael_leachim wrote:
| 100% second this, thank you
|
| it is hard to say almost 99% product is not engineering but
| what it enables company to do. In a sense this division is
| psychological: either company cares about engineering and
| makes it a priority or it doesn't.
|
| I think good proxy would be tooling which company uses,
| niche languages like Clojure/Erlang, open source activity,
| well known people in decision making positions rather than
| specific business type.
| vegetablepotpie wrote:
| As a third bullet point person, never ever attempt to solve
| interesting technical problems.
|
| I've made that mistake, I've been asked into meetings and asked
| "how's it going" then promptly told "don't tell me the
| details."
|
| Working in bullet point three means working on boring,
| forgettable solutions. You may find yourself making valid
| technical solutions that are political suicide.
| jimbokun wrote:
| To simplify, you always always always want to be working in
| bullet point 2, if at all possible.
|
| In the other two, you are a cost to be minimized or eliminated.
| Only if you are working on one of the companies core products
| are you an asset bringing revenue into the company.
| jonfw wrote:
| With #1- you are the product
| Closi wrote:
| All jobs are transactional, the transaction is just more
| clear-cut with #1.
| Closi wrote:
| I disagree - It depends on your career aspirations, your
| skillset, the company, and the type of software you like
| making.
|
| If you are a great communicator and have a great ability to
| just 'get stuff done', you might be a superstar in 1 & 3, and
| you might find working in bullet point two highly
| frustrating.
|
| With number 2 you are more likely to be working on a tiny
| part of a larger application.
|
| My brother went from bashing out big scrappy functional
| software with lots of client interaction (option 1 or 3) and
| moved to a bigger product organisation where he is suddenly
| working on a team building a microservice for a larger
| application, but doesn't feel like he is making the same
| direct impact (i.e. it can be more satisfying to make 10
| people's jobs 10% easier compared to than making 1 million's
| peoples jobs 0.1% easier). He would rather build some scrappy
| tools that gets the job done than build highly refined
| software, just because the scrappy programming to meet an end
| is more satisfying to him (and is generally the bit where you
| can build fast value!).
| chii wrote:
| > (i.e. it can be more satisfying to make 10 people's jobs
| 10% easier compared to than making 1 million's peoples jobs
| 0.1% easier)
|
| i think in this case, it's got nothing to do with the
| impact, but to do with the intimacy with the users. This
| has more to do with the organization rather than the
| category outlined in the OP.
| Supermancho wrote:
| As a software developer, I rather work at a company that
| sells billions of dollars in merchandise, with a huge
| amount of software to maintain doing that and endless
| middle management ideas to build on (most of which won't
| amount to anything). Job security. Lots of opportunities to
| move around and nobody needs to know how the reference was
| about all the s-shows, when you go somewhere else.
| ted6767 wrote:
| I would also add career longevity and security. I work at a
| number 3, I wrote and maintain all the logistics stuff.
| Every product they sell goes through my code to package
| parts, put it together and get it out the door. Average
| time working here is measured in decades not years. It
| would take a new person roughly a year to figure out what's
| going on. It's incredibly complicated cash cow that
| complies with a slew of national and international
| regulations related to health care. I know more than I ever
| want to about HIPAA, international equivalents and
| transportation of hazardous and infections goods.
|
| I wouldn't mind switching to #1 and doubling my paycheck
| but for now I could float here until I die, and many do.
| granshaw wrote:
| How's the workload?
| killjoywashere wrote:
| Labcorp?
| ravenstine wrote:
| Eh, I don't think it's that clear cut. I've worked in all
| three types, and there were positives and negatives to each,
| and none are necessarily better than the other. I will say
| that #2 tends to be the most reliable and tolerant of your
| faults.
| michaelsalim wrote:
| It depends on the person and the company as others have said.
| Personally, I found no 3 to be pretty nice in competent
| companies. On the other hand, I wouldn't want to work with
| companies like no 1 again. And no 2 can be quite a mixed bag.
| sbrother wrote:
| Actually #1 is my favorite, as I'm better at technical sales
| and rapid prototyping than I am at slow, FAANG style
| politicking, planning, risk mitigation and eventual
| development. I've done both at various points in my career
| and consistently make about ~twice as much money running my
| own consultancy, not to mention I'm so much happier in that
| environment.
| granshaw wrote:
| Do you get much stress in terms of sometimes not being
| "rapid" enough, not having anyone to rely on apart from
| yourself (assuming you're solo), and finding business?
| sbrother wrote:
| Not really, because I always maintain at least a few
| clients so I'm not too worried about losing one. Once you
| have a solid pipeline, losing a client becomes just part
| of the business, not the scary emotional experience of
| "getting fired".
|
| And I have a network of other independents I can bring in
| to help out with things. They're a good source of leads
| for me as well.
| hgomersall wrote:
| Most companies should treat software as a core product. Not
| many do.
| patmorgan23 wrote:
| Nah there's still tons a variability. Some companies are
| great some are poor, and different people like working in
| different environments. #2 might be YOUR ideal workplace but
| it's not everyones.
| electrondood wrote:
| > Is your company selling software development hours
| (consulting)?
|
| From working with contractors, this bucket also motivates you
| to strongly optimize for number of sprint points delivered, not
| quality/reusability/maintainability.
| kayodelycaon wrote:
| I chose to make a career out of #3, specifically logistics. I
| know how stuff gets from vendor to customer.
|
| This isn't something you can buy out of a box. It's usually
| heavily customized and made out of multiple systems were never
| design to work together. Every company does this differently.
|
| I enjoy this. I'm good at thinking through whole systems across
| a company's many departments. This requires knowledge of
| internal politics to navigate through problems. This is were
| I'm valuable. As a programmer, I'm good, but can't match the
| expertise of someone who makes a career out of programming.
| ted6767 wrote:
| Brother
| ptsneves wrote:
| I am in the same camp. I also don't think it is bad in
| compensation terms because lots of this maintenance work is
| often called devops and devops is well paid from my point of
| view. I do the logistics for embedded or SaaS. It has been
| good and it is often cool to login to devices that are seen
| as a black box by any other person in the world. I also know
| that when something is on fire the maintenance guy is the one
| being begged by the sales guys and higher management.
| Maintenance people end up being debugging gods.
| DayDollar wrote:
| Missing the hackernews part of product to research and
| development,: Is your company planning to use the exponential
| growth nature of software to enter into a overlooked niche or
| rapidly take over a existing industry? In that case, product
| development does not really catch the situation. Cause using
| the situation, closing time window till competition appears or
| funds run out, is way more important than the product or its
| quality
| shermantanktop wrote:
| Seems like a variation of #1 where the rewards are
| probabilistic and lumpy. I agree that the motivations and
| resulting behaviors end up pretty different.
| irrational wrote:
| > Is your company selling something else that has a software
| component or that software enables (pretty much every other
| company)?
|
| I'm not sure this is true? If my company sells food or clothing
| or shoes, they don't have a software component. I'm not sure
| what the breakdown is, but my gut feeling is "pretty much every
| other company" is wrong.
|
| I work for a company that makes clothing and shoes. We have an
| enormous tech organization, but we aren't a consulting company,
| don't sell software, and don't put software into our products.
| jeremyjh wrote:
| This is an article about software engineering - for software
| engineers. In this context it should not be hard to reason
| that companies that do not employ any software people are out
| of scope. Of course they exist.
| irrational wrote:
| But, my company does employ thousands of software people.
| We just don't sell consulting, sell software to other
| people, or sell products that use software.
| alephnerd wrote:
| I'm guessing GAP.
| digging wrote:
| You misunderstand. The third group is not only companies
| that sell software-based products, the third group
| includes companies that use software to sell their
| products or manage other aspects of the business. Having
| an in-house online store is an example.
|
| That presumably puts your company in that group, just
| like mine (or else I have no clue what thousands of
| software people would be doing on the payroll).
|
| I bet our two companies have very different reliances on
| technology, but we're both in the same group, because all
| of our software supports our sales of our actual goods
| and services.
| alephnerd wrote:
| Logistics and e-commerce is a component of commerce (aka
| selling)
|
| That said, you will absolutely be a cost center.
| toast0 wrote:
| Your shoes and clothes don't have a software component (well,
| most don't), but in most producers, software enables their
| production.
|
| Inventory management, production automation, order management
| is software at pretty much every company now, because doing
| it with paper or in people's head is error prone. I imagine
| your tech organization is in an enabling role.
| OJFord wrote:
| > If my company sells food or clothing or shoes, they don't
| have a software component.
|
| E-commerce? I can't think of any chains without a website, or
| any large enough that 'company' seems apt that don't sell via
| it.
|
| > I work for a company that makes clothing and shoes. We have
| an enormous tech organization, but we aren't a consulting
| company, don't sell software, and don't put software into our
| products.
|
| Ok that's the 'or that software enables' isn't it?
| irrational wrote:
| I guess we are interpreting the third bullet point
| differently. I interpreted "Is your company selling
| something else that has a software component" as something
| like a car that has software built into it. And, I
| interpreted "or that software enables" as something like a
| board game that requires the use of a mobile app (like The
| Search for Planet X). In other words, the products are not
| useable without the software. Whereas, a t-shirt doesn't
| have a software component and isn't enabled by software
| (though, I could imagine a t-shirt with a QR code that is
| enabled by software, but that isn't the norm).
| mooreds wrote:
| Ah, sorry, when I wrote "that software enables" I meant
| you use some kind of software tool to help ship your
| product or service. That could be excel macros, SAP,
| custom POS systems or anything else. If it is customized
| or built in-house, you'll need developers.
|
| Sorry I wasn't clearer.
| golergka wrote:
| Retailers of all kinds employ enormous amount of data
| analytics, data engineers and software engineers.
| OkayPhysicist wrote:
| Pepsi's hiring Elixir developers for their backend and
| logistics systems. Pretty much every company of significant
| scale realizes they can either save money or gain some
| advantage from using custom software.
| dver wrote:
| Very much this.
|
| What ever is being manufactured, the real product is data
| for process improvements, improve product quality.
| patmorgan23 wrote:
| Not every company hires software developers of course. But
| every type of business will when they get big enough. They
| may not call them developers but I bet you have some people
| doing business process automation that are basically
| developers.
| hackernoteng wrote:
| My experiences: 1) programmer in IT department of major
| newspaper: disregarded as IT geek. very small salary. the worst
| office spaces. 2) senior engineer in software startup: rockstar
| treatment, stock options, all the things you would expect as
| office culture 3) senior consultant at IT consulting company:
| must basically be a sales guy who writes good PowerPoints.
| Maximize billable hours. What ever you do dont complete a
| project quickly or with minimum amount of code.
|
| you can probably guess where I am now.
| hackernoteng wrote:
| The consulting company gig paid alright. and all the guys who
| stayed got really rich due to IPO. I left the second my
| options vested. Literally when the transaction went
| through... no regrets because it SUCKED
| granshaw wrote:
| How often do consulting companies ipo nowadays tho... heck
| ipos in general have dwindled to a tiny number
| jwineinger wrote:
| Agree with these. I was a dev at a retailer that did
| catalog/phone sales and was starting to use web. Small
| salary, small PTO, no benefits. Pay increased when the
| business had an existential crisis and came to rely much more
| heavily on tech. Next was software consulting company
| churning out sites designed by marketing agencies, billed to
| the 15 min. Small salary, small PTO, some benefits. Then I
| went into SaaS (startup, then a public company). Nice salary
| + stock, great PTO, great benefits.
|
| Aside from the comp/PTO/benefits, I learned that consulting
| isn't for me. The client interactions felt... adversarial,
| where they were trying to get more work for less money, while
| we were doing the opposite. I did not like that constant
| tension in conversations.
| SOLAR_FIELDS wrote:
| The point you made about consulting interactions resonates
| with why I also ended up not liking consulting. It feels
| like incentives are not aligned when doing software
| consulting a lot of the time.
| jncfhnb wrote:
| Flat fees. Problem solved.
| tessierashpool wrote:
| flat fees fail for dev.
|
| as soon as you encounter an unexpected problem, your
| margin suffers. since unexpected problems can radically
| alter dev time, your margin can be obliterated.
| jncfhnb wrote:
| Make bigger margins
| JasonSage wrote:
| Not sure why you're getting down-voted.
|
| If unexpected costs are shrinking your margin, you're
| failing either:
|
| 1. ...to negotiate the terms of your agreement correctly
| (what constitutes additional scope and therefore
| additional charges?). I will never take another client
| project without first agreeing on an SRS for this reason.
|
| 2. ...to negotiate a fee with a margin proportional to
| the likelihood of unexpected situations arising. This is
| a function of the accuracy of requirements by
| simple/complicated/complex problem domains. I think this
| is what parent is suggesting.
|
| If clients don't like (2) they will work with you more on
| (1) by providing more accurate requirements, which lets
| you bucket some problems into more readily estimable
| domains.
| jncfhnb wrote:
| Yeah. My answers are short but they're genuine.
|
| What you're saying is a much clearer answer. And what
| you're saying is frankly pretty tough. But being a
| consultant is more than just asking someone to shut up
| and and pay you to code.
| chasd00 wrote:
| > Make bigger margins
|
| if you can maximize margin on all fixed price work while
| not pricing yourself out of the market you will dominate
| software dev and also make millions selling books. hint:
| it's not that easy.
|
| handling fixed price software dev is like handling
| dynamite.
| tamimio wrote:
| Curious to know every consultant flat fees and/or the
| metrics they use to determine it, since you will be
| charging for the "value" rather than the fixed hourly
| rate.
| A1kmm wrote:
| I think it is flat fees which create the problem in the
| first place. There are six commonly recognised general
| project variables: cost, time, scope, quality, benefit,
| risk.
|
| So suppose you've fixed cost, have you fixed the other
| five project variables too? If yes, you've just
| reinvented waterfall - which is fine if you have a very
| well defined task you repeat often, and there is little
| chance of much scope variation being desirable. It still
| might be adversarial in that you, as a consultant, might
| do the same process for every client, but it might be
| your first time working with a client, who expected more
| than the scope, or disagrees with your interpretation of
| the scoping document supplied.
|
| Now suppose it is a much more bespoke task, where both
| sides need to discover some things about what works. You
| are likely to learn that part of the plan you originally
| had won't work to capture the benefits. Now the actual
| scope required is bigger; perhaps that is a risk you
| take. But perhaps one client realises some big scope
| requirement early, and deliberately takes advantage of
| the fact your scope is variable to conceal this from you
| when you set your fixed price; maybe you put some
| language in to try to reduce this risk. And perhaps your
| boss encourages you to use some of that language on an
| honest client who did genuinely try to communicate the
| scope, to make the client pay. Everything is once again
| back to being adversarial.
|
| I think time and materials contracts are actually the
| best for aligning incentives - the consultant gives their
| best attempt at an accurate estimate of the work, and the
| client can freely change things as they go along - but
| carry the risk of cost changes. If the consultant is poor
| at estimation, doesn't give frank advice, or does low
| quality or slow work, the client ends the contract with
| the consultant and gets a better consultant, and since it
| is time and materials, it is clear what is payable and
| who owns what - so ultimately everything is well aligned.
| teaearlgraycold wrote:
| > Maximize billable hours. What ever you do dont complete a
| project quickly or with minimum amount of code.
|
| OOF
| antod wrote:
| _> Maximize billable hours. What ever you do dont complete a
| project quickly or with minimum amount of code._
|
| There's a real continuum of engagement budget here - at the
| other end of the scale you have the opposite problem where
| the fees are barely adequate, and your success is based on
| systemitizing shortcuts to crash out cookie cutter minimum
| viable products, and being able to get clients to actually
| cough up.
| golergka wrote:
| > Is your company selling something else that has a software
| component or that software enables (pretty much every other
| company)? In this case, you'll be valued for your ability to
| deliver on or below budget and you'll never be the star of the
| show.
|
| Trading companies are one of the very innovative in IT and
| offer software engineers salaries that are higher that FAANG.
| hinkley wrote:
| > you'll never be the star of the show.
|
| This is far too kind. If you work eg for a hardware
| manufacturer, not only won't you be the star, but good luck
| getting any respect. You are a cost. One they wish they didn't
| have to pay. Delivering on time and under budget doesn't put
| you on their radar, it takes you off.
| badpun wrote:
| Depends on the hardware manufacturer. From what I know,
| developers at Intel are treated pretty well. It all depends
| on how integral the software component is to the overall
| product's market success. In the case of Intel, a GPU with
| poor and buggy drivers is not gonna sell, so software is
| pretty important.
| hinkley wrote:
| Isn't Intel struggling now because their definition of
| 'pretty well' wasn't good enough and they lost key people
| to competitors?
| deadbabe wrote:
| #2 is the best because if you can do your job quickly and
| efficiently you can minimize the amount of actual time you
| spend working as long as you are delivering the software.
| mastersummoner wrote:
| Well I agree with you, there are definitely developers out
| there who are completely happy with a 9 to 5 punch card type
| job.
| DeathArrow wrote:
| What if you are one of the only few who know how to maintain a
| Cobol system for a bank? Aren't you very valuable?
| Nextgrid wrote:
| There's nothing particularly difficult about Cobol, it _can_ be
| learned, and with enough effort, all the undocumented existing
| code can be understood and reverse-engineered enough to be able
| to make changes. It 's not pleasant work, but it's doable.
|
| If there was value in it, salaries/consulting rates would
| reflect it and people would be queuing up to learn it and make
| good money. That isn't happening, so it seems like Cobol devs
| aren't actually _that_ valuable to these companies.
| andyjohnson0 wrote:
| There was a comment on HN a while back to the effect that the
| well-known stories of COBOL devs being dragged out of
| retirement to earn massive consulting payments was a myth.
| They were actually being paid good, but not extremely good,
| rates for their knowledge of the business logic embedded in
| old code-bases. The implementation language was largely
| irrelevant.
| izacus wrote:
| You're valuable in a way where everyone really wants to get rid
| of you and is planning hard on how to do that.
| w4tty wrote:
| No. Because COBOL maintenance is outsourced to the third world.
| vanderZwan wrote:
| Do you seriously suggest that _banks_ outsource the
| maintenance of the mainframes that process their money
| transfers? If so I 'd like to see a source, because the only
| articles I have read about on this topic (e.g. [0]) tell me
| the exact opposite: it's all in-house the risks are too high.
| For larger banks it's practically a national security risk.
| Maybe the software they use is from abroad (usually ancient
| IBM shit), but that's not the same.
|
| [0] https://ezali.substack.com/p/interviewing-my-mother-a-
| mainfr...
| nijave wrote:
| They don't "out source", they in-source by opening
| technology hubs in cheaper locations.
| vanderZwan wrote:
| Again, I would like to see a source. I'm not saying
| you're wrong. Maybe you're talking about small banks in
| the US or something, of which I know basically nothing. I
| am thinking of examples like Nordea, the bank in the
| article I linked, which has a market share of around 20%
| in Sweden[0] _and_ handles the government 's bank
| accounts. Especially that last part makes me extremely
| skeptical that the Swedish government would be OK with
| handing over the keys to their economic kingdom to cheap
| digital labor abroad so a company might save some money.
|
| [0] https://en.wikipedia.org/wiki/Nordea#History
| geodel wrote:
| Well my brother worked in BNY Mellon India center. They
| have thousands of people and work core banking
| processing. BofA have their own India development center
| with thousands of employees. And this is outside of 10s
| of thousands outsourced to Tata, Infy etc.
|
| You think core banking process like transfers/ trading is
| some kinda crown jewel. It may be in terms of _messaging_
| but most of core IT part is just a cost center.
|
| Customer data and all need to be in their own secure data
| centers for legal reasons but all the processes can be
| designed, developed and executed from anywhere at lower
| cost.
| lifestyleguru wrote:
| People get overly excited by some "last man standing" success
| stories of a COBOL developer based in US of A. My only
| encounter with COBOL developer was a freshly graduated girl
| based in post Communist country, her earnings were something
| around 25k EUR annually. I pointed out that her career might be
| something of a dead end but she was more like "a job is a job".
| Oh, and they were using some dinosaur version control as well.
| ponector wrote:
| I've seen a post on local job board in Poland, IBM was
| looking for junior cobol engineer. Any student with some java
| knowledge will fit, they said. I'm sure they will not pay
| anything more than 25k eur anually.
|
| Also if there is some legacy cobol system, many managers are
| incentivised to gather a new team to write a replacement with
| some modern technology stack. Cobol is definitely a dead end
| for the career.
| lifestyleguru wrote:
| > legacy cobol system, many managers are incentivised to
| gather a new team to write a replacement with some modern
| technology stack.
|
| Absolutely not in outsourcing centers like this. You're not
| supposed to show any initiative or god forbid - design
| anything. You grunt the COBOL until budget for the project
| is zero.
| rgblambda wrote:
| >her earnings were something around 25k EUR annually.
|
| That's a fairly good salary for a recent graduate in Eastern
| Europe.
|
| Although I admit it does illustrate your point that some
| legacy tech stacks are quite easy to pick up.
| chasd00 wrote:
| > What if you are one of the only few who know how to maintain
| a Cobol system for a bank? Aren't you very valuable?
|
| The bank would see the situation (only one person knows the
| Cobol system) an extreme risk and do whatever it takes to
| mitigate that risk. The short term answer is to keep you hired
| but the long term answer is to either find a steady supply of
| Cobol programmers or move away from Cobol to something where
| expertise is more available.
| DeathArrow wrote:
| I think profit center vs cost center is a better model.
| vanderZwan wrote:
| Why not combine them? Both give different insights that could
| complement each other, no?
| verinus wrote:
| But I think it has a lot to do with how profit is made: if
| you sell machinery for example that has a software part you
| are a cost factor, even if software is required to run it.
| Think of it as an in-house supplier that could even be
| outsourced. Not that I think it is feasible, but upper
| management does. And as long as they do, you won't rise far
| building software in such a company...
| joshka wrote:
| This has been how I've usually define it too.
|
| I like the addition of the R+D section because I think a good
| Maintenance oriented team should be doing R+D related to
| bringing their maintenance costs down the same way a good sales
| team would be doing R+D to bring their sales profits up.
| LudwigNagasena wrote:
| I think it's a nonsensical model. Every department is ideally
| responsible for both revenues and costs. If you can't measure
| it, it is a problem of your KPIs. So the KPIs may be cost-
| oriented (and thus badly aligned), it doesn't make the
| department itself a cost center.
| Kudos wrote:
| Which department are you talking about? If your department
| doesn't drive revenue, then the business leaders will see it
| as a cost center. It doesn't matter if you disagree with that
| perspective unless you can change their minds. How have you
| done that in the past, or hypothetically how do you think
| that might work?
| anticorporate wrote:
| This has been my experience as well.
|
| It doesn't matter how many presentations and case studies
| and financial models you build, whether you're a cost
| center or not is basically entirely determined by what a
| few people in the c-suite believe. This became blatantly
| clear over the past year or so of layoffs, when the same
| people who nodded and thanked teams for showing them how
| they generate revenue for the business immediately turned
| around and put them on the chopping block.
| LudwigNagasena wrote:
| It doesn't become any less nonsencial just because some
| business leaders who are still stuck in 1980s believe in
| it.
|
| Both profit centers and cost centers are supposed to
| increase profit, otherwise you wouldn't hire those people.
| If a department doesn't drive profit, then just axe it and
| stop wasting money on it. If you can't [1], then it
| actually drives profit, you just have no idea how. The fact
| that you can't set proper KPIs to measure impact doesn't
| imply absence of impact, and of course it doesn't imply
| that you should treat it as if it has no impact.
|
| Departments are engaged either in primary or support
| activities. And those activities are either efficient and
| optimal or not. Your competitive advantage doesn't even
| have to be your primary activity. If you are successful at
| making fidgets because you hire, plan and budget better
| than others in your industry; what insight can talking
| about profit centers and cost centers provide to you?
|
| [1] How is someone supposed to run a company without HR or
| accounting?
| count wrote:
| You redefined cost / profit center as 'primary' or
| 'support'. This is a circular argument.
| Gormo wrote:
| The cost center vs. profit center concept has some
| utility for accounting, but overall it makes more sense
| to model the business as a modular system seeking a
| global optimum, a la Goldratt, rather than a set of
| separate sub-organizations each to be optimized
| separately.
|
| In other words the _business as a whole_ should be viewed
| as a singular profit center, and each department or
| project should be evaluated in terms of how much it
| contributes to optimizing the overall performance.
| grecy wrote:
| > _It doesn 't become any less nonsencial just because
| some business leaders who are still stuck in 1980s
| believe in it._
|
| Of course it does.
|
| Whatever your business leaders believe _is_ reality in
| that company. It makes no difference what you or the
| outside world believe.
|
| You're either OK with it, or you need to get out ASAP.
| feoren wrote:
| "Business leaders" are almost universally short-sighted,
| narrow-minded parasites focused on trying to fatten up
| their own division so they can suck more of its blood for
| 2 or 3 years before the next Musical Chairs game when
| they'll compete with all the other psychopathic mouth-
| breathers for the best seat, regardless of whether they
| know a damn thing about whatever division or company they
| end up in and subsequently pretend to "lead". It's an
| entire societal caste of pathetic, worthless, ambivalent
| assholes cosplaying as Business Magicians in order to
| compete in their own corrupt feudalistic games against
| each other to win the fattest host to parasitize. It's
| the modern day Priest Caste. If you "get out ASAP" from
| such companies, you will have _nowhere to work_.
| grecy wrote:
| I agree with everything you said, right up until the end.
|
| I do believe there are still organizations (or at least
| teams within) that have not been taken over by the
| parasites you describe. It takes hard work and a lot of
| looking, but they can be found.
| marcosdumay wrote:
| It is a completely nonsensical model, and leads to completely
| stupid decisions if applied.
|
| But management uses it for every decision anyway.
| thiago_fm wrote:
| It doesn't matter where you work at, when layoffs come, the
| executives will care about location, timezones, desire on
| finishing the current project you are working on, (maybe)
| performance etc. There are too many criteria and no clear pointer
| on what is safe and what isn't.
|
| Being part of a layoff and also watching other colleagues coming
| from other Big Tech companies share their experiences, you'd see
| people laid off from literally everywhere: key projects, R&D (I
| was part of), sales, high-performing etc.
|
| It's a financial decision, the cut NEEDS to happen once the
| higher ups have decided and you can be cut, for you as an
| employee, anything can happen.
|
| Lots of R&D people end up being on the chopping block as well
| because you could be suddenly in a very promising project, but
| that the company no longer cares about, because some executive
| above even the boss of your boss told it isn't a priority.
| vsnf wrote:
| The higher up the org chat you report to is, the safer your
| position becomes. At one job, I reported directly to the still-
| reigning cofounder of a long lived company. Never have I felt a
| stronger sense of job security than that.
| vasco wrote:
| It's different security. Like in game of thrones in that
| scenario you're as safe as your boss is, which will depend on
| the evolving politics. Even founders get housted sometimes,
| but I'd agree that I'd choose your scenario over others.
| gtirloni wrote:
| I can totally attest to that. I once worked for a company
| where the CTO that was 3-4 levels above hired me directly
| and I reported to him. It felt very empowering and
| motivating because I was working on what he considered a
| critical area for the day-to-day of the company. Once he
| was gone, I suddenly was a huge problem to all the middle
| managers that disagreed with the CTO.
|
| If you happen to be in that situation, better to watch Game
| of Thrones (which I did only for entertainment not for
| work-related reasons). Ignore politics (like I did) at your
| own peril.
| mooreds wrote:
| What would you have done differently? Built a better
| relationship with the middle managers? Kept your ear to
| the ground and left before the CTO did? Interviewed every
| quarter so you'd be able to leave and land elsewhere?
| Something else?
| gtirloni wrote:
| I think better relationship with middle managers and
| maybe leave with the CTO if it made sense (it didn't, in
| my case). I was too focused on doing things and assumed
| the CTO was taking care of "winning the hearts" of middle
| managers. He wasn't. It was a very top-bottom initiative
| and that rarely works when culture is involved.
|
| So yeah, I think I should have "managed up" so this
| initiative wasn't tied to the specific CTO but was a
| common agreement. If the CTO wasn't doing that, I guess I
| should have called his attention to it or done it myself.
|
| To be honest, middle managers not thinking it was
| important is just baffling but that's another long story.
|
| As for keeping ear to the ground, I wouldn't even attempt
| that because I really suck at that (and it's distracting,
| I'd rather leave). But many people have success with that
| approach.
| bomewish wrote:
| There's a troubling/fascinating implication here:
| generally we just want to 'do the thing', but it's rarely
| that simple.
|
| Often to be able to just 'do the thing' you have to game
| out a bunch of this political/strategic stuff, and start
| maneuvering across those dimensions, in order to create
| or maintain the conditions under which you can just keep
| doing the thing.
|
| Yet the more you do that, and the more you think in that
| way, the less of the thing you're doing...
| maxrecursion wrote:
| >>"He wasn't. It was a very top-bottom initiative and
| that rarely works when culture is involved."
|
| I work at a very large organization where the top is too
| scared to give any direction whatsoever, so it's middle
| managers and their lower staff henchman, that battle it
| out over major decisions with politics and schemes to get
| their preferred stuff implemented. It's more terrible
| than you can imagine, I never seen a more chaotic place.
|
| So, I just want to say top-down management isn't the
| worst thing. I'd prefer that to no top down management at
| all.
| gtirloni wrote:
| I'm on the same page. The problem in this case was a very
| hands-free approach to management that suddenly changed
| to top-down when the chaos produced almost daily outages.
| So the very relaxed environment now had to somehow have
| rigorous engineering practices... mandated from the top.
|
| Reminds me of holacracy and how companies picked up the
| pieces after that fad went away.
| vincnetas wrote:
| Because no manager would layoff him selfs even if his
| position and project is obviously unnecessary. In other words
| only above people can layoff below people :)
| lp4vn wrote:
| I already worked for companies where there were management
| changes at a crazy pace, I'm not sure that all of them got
| promoted and I have the impression that some of them might
| have been fired as well.
|
| I don't want to start a flame war but it's much easier to
| replace a manager than a technical person, a technical job is
| boring and most people don't want to do it while management
| relies more on soft skills, something that most people can do
| at a minimum level. Being a manager who's always employed is
| more about social connections, if you don't befriend the
| right people your job security might also be at risk.
| forgotusername6 wrote:
| Most people don't want to do technical jobs? That's not my
| experience at all. We've had vacant management positions
| for months because nobody wants to do that role. We'd get
| no volunteers internally and only a handful of suitable
| candidates would apply from outside.
| lp4vn wrote:
| If you ask people who come here, probably most of them
| would choose a technical over a managerial position, but
| I talk about the general population, of course. Being
| someone who coordinates the work of other people is much
| more amenable to human nature than banging your head
| against a many times unintelligible mass of code.
|
| But you can always check on linkedin the many hundreds of
| people who apply to any managerial position.
| apwell23 wrote:
| trick is to hire women into technical positions and fast
| track them into management. My company uses this strategy
| and almost 90% of low/mid management and admin are women.
| apwell23 wrote:
| > The higher up the org chat you report to is, the safer your
| position becomes
|
| Last layoff at my company was predominantly of middle
| managagers and very few line workers. Even meta layoff was
| "the flattening".
|
| surprised by your comment. Is there any data supporting this?
| vsnf wrote:
| No data, just an intuition about being closer to the power
| centers.
| apwell23 wrote:
| I guess that makes sense. Level 1 and 2 managers are not
| really closer to power centers despite being higher in
| the org chain.
| austin-cheney wrote:
| In my experience there are two things that bring layoffs: poor
| sales and bad product management.
|
| When I was at Travelocity they had by far the best brand
| awareness and marketing. They also had the best pricing
| algorithms resulting in massive profit margins compared to the
| competition. Nonetheless they were destroyed in the
| marketplace. The biggest killer is that Expedia invested
| heavily in sales to the sacrifice of everything else eventually
| resulting in inventory relations teams 3-5x greater than what
| Travelocity could dream of affording. That was enough to
| achieve market dominance for Expedia.
|
| Then to make that worse Travelocity only understood growth
| which was a colossal strategic failure executives would repeat
| over and over. When it became clear to the original executive
| team they simply left the company. There was a later executive
| that doubled down on this and in one year converted a $100
| million business to a $60 million business. That guy is still a
| travel industry executive.
|
| The final nail in the coffin is poor product. It would fail at
| checkout thereby dropping sales and those customers would never
| come back. It costs too much to maintain because of poor
| decisions about software execution. They would also make bad
| decisions about new initiatives until they doubled down on A/B
| testing. Then to compensate for all these product failures they
| would over invest in advertising which drove more customers off
| the site.
|
| Poor software execution resulted in my layoff from my previous
| job. The thing that has saved me from layoffs in the past was
| having a skill that was both essential and difficult to replace
| just by hiring. The thing that resulted in my layoff from the
| last job was a fragile product and the unwillingness to fix
| that product. This is why I have abandoned any kind of web
| related work. More often than not terrible decisions are
| intentionally made on the basis of immediate people replacement
| or immediate feature delivery without regard for how shitty or
| expensive the new feature is. So much of the time it feels like
| children are running the daycare because people with inadequate
| experience want to visibility and nobody wants to clean up
| their messes.
| lazyasciiart wrote:
| Salesforce layoffs had no internal cause - just "investors
| want us to cut costs". They selected people at random, and we
| lost tons of people who were essential and difficult to
| replace. Then they said "we can't guarantee there won't be
| more, and we can't tell you any way to avoid being hit". And
| then they said stuff about productivity going down but I
| didn't care, surprise!
| austin-cheney wrote:
| Nobody wants to believe that they are easy to replace... as
| they are laid off and replaced. So, comment redacted.
| abirch wrote:
| Peter Drucker called random firing amputation without
| diagnosis.
| gtirloni wrote:
| Same situation at a different company, except they kept
| telling us "we made sure this won't keep happening". Of
| course few people believed and we lost many good engineers
| that simply left because they couldn't have a major source
| of income coming from such unstable place.
|
| I like to believe executives know their workforce will
| shrink more than the layoff numbers. They must know this.
| They also must know it will be harder to hire new people.
| They know this, right? Please someone tell me so.
| mlrtime wrote:
| >They must know this. They also must know it will be
| harder to hire new people. They know this, right? Please
| someone tell me so.
|
| What time horizon are you thinking? People will forget
| '22/'23 layoffs very quickly. This is especially true if
| you made it through these last years, the market picks up
| and you want to move.
| gtirloni wrote:
| I have no doubt people will forget in time (<5 years).
|
| But anyone looking for a job ought to do due dilligence
| when things pick up again and at least set the correct
| expectations about how long their relationship with the
| company could last if the market turns bad again.
| geodel wrote:
| Why? If anyone frequented this or many other forums
| they'd know employers can terminate employee any time
| without any reason whatsoever. Leave the job with as
| little notice as possible because employers absolutely do
| not care for you. And when last year it did happen people
| here are feeling _hurt_ as if forever job promise is
| broken.
| dangus wrote:
| I think this example is way more common than the situation
| your parent commenter described. Most corporations don't
| seem to be identifiably strategic about layoffs. They don't
| make a coherent plan until the shit hits the fan and the
| board dictates that a certain percentage must go.
|
| I've been laid off three times and not once was my layoff a
| result of a coherent strategy or reflective of my
| utility/value to the team.
|
| The first time, I was an accounting mistake. The company
| quite literally hired me and numerous other contractors by
| accident. The bean counters in corporate simply weren't
| talking to each other and hiring managers somehow got their
| reqs through.
|
| The second time, I along with my new hire cohort was laid
| off a month after my start date. I'm not even sure how a
| company is so disorganized that they can go from approving
| new hires to laying off those same new hires within a time
| period that couldn't have been longer than 3 months.
|
| The third time was similar except that it took place in a
| slightly longer timespan, still less than a year. Company
| management handled growth immaturely and irresponsibly,
| choosing to bulk hire then lay off the cohort rather than
| growing more conservatively. Paying 5 employees for almost
| a year could have paid for one employee for over 3 years,
| no layoff necessary.
| marcosdumay wrote:
| > Salesforce layoffs had no internal cause
|
| This is the shared theme of most of the recent layoffs.
|
| I don't know where the GP is coming from. Layoffs with
| clear and local causes seem to be a tiny minority.
| Guid_NewGuid wrote:
| Maybe someone who knows more about this stuff can enlighten me.
| From what I've heard there are actually only 2, opex and capex.
|
| If I recall correctly capex is better for the business because of
| how it gets treated in the accounting stuff. This naturally gives
| rise to the feature factory style work of a lot of dev jobs. Some
| reason like they can record capex spend as an asset with
| depreciation. Is this true?
| zer00eyz wrote:
| This is close, there is more nuance to it, and a lot of it is
| going to be specific to your org.
|
| If you work in office, and there are accountants there go make
| friends. They are just another flavor of nerd, so you're gonna
| get along with them, and they have insights into the company
| that you will never get outside of the C level.
|
| IF you dont KNOW the answers to accounting questions, take some
| classes. Candidly this is a function of every business that
| engineers should be aware of! The projects that cost money
| upfront (OPEX) and can provably reduce recurring costs (CAPEX)
| can be HUGE wins for all involved.
|
| There is a story about how Dr's in the US have no idea what a
| procured costs, and that many non us ones do. Though the
| example is about insurance, I think the lack of awareness of
| costs is pervasive in more places. Do you know your AWS spend?
| Do you know the per customer cost/spend (is that individual or
| organization).... These numbers start to matter in a value
| engineering situation.
| radiator wrote:
| > The projects that cost money upfront (OPEX) and can
| provably reduce recurring costs (CAPEX)
|
| So you mean OPEX are upfront costs, and CAPEX are recurring
| costs?
| marcosdumay wrote:
| Yeah, whatever mistakes the GP did, those names are the
| other way around.
| zer00eyz wrote:
| Yes I did transpose them!!! I have since had coffee and
| am feeling much more on the ball, thanks for catching my
| error folks!!!!
| datadrivenangel wrote:
| Capital Expenditure (CAPEX) is the money invested up front,
| and Operational Expenditure (OPEX) is the money invested to
| operate the investment as you go.
| smugglerFlynn wrote:
| 3 parts of organisation mentioned in the article have their own
| respective Operating Expenses (OpEx) and Capital Expenses
| (CapEx). OpEx is what you spend on day to day activities, and
| CapEx is what you invest into something that you will use long
| term. You can pay via CapEx or OpEx for the same exact result:
| e.g. if you purchase a car, that's CapEx, but if you rent it
| each month, that's OpEx. I'm simplifying, but that's the gist
| of it.
|
| Organisations tend to move away from CapEx where possible,
| because of _two reasons_ :
|
| 1. management decisions require accounting know-how and
| accounting 'magic' when CapEx gets involved
|
| 2. large upfront investments are much less flexible and more
| risky than day to day expenses
|
| Let me illustrate.
|
| Your marketing department is investing into new on-premises IT
| system to run promotions and campaigns. They are spending $1M
| dollars upfront for the installation, equipment purchase,
| system licenses and so on - all these expenses will be booked
| under CapEx. That marketing department also pays day to day
| salaries, and some other regular expenses, which all go to
| their OpEx.
|
| Let's say right after system is launched and everyone in
| Marketing starts using it there is a 30% growth in # of leads
| they bring, and resulting 10% growth in sales. But what does
| that mean, financially? Was the project a success? 10% growth
| in sales might not cover full cost of our $1M investment, so
| for how long would we need to keep up the growth in order to
| see returns? What growth numbers do we need to keep seeing?
| What if we decide to adjust and purchase more hardware and
| licenses as we go? What if system unexpectedly required us to
| hire extra people in marketing, bumping up department's OpEx?
|
| All that requires calculation, recalculation, excel
| spreadsheets crunching, more spreadsheets, and a few fat decks
| of powerpoints just to align all the decision makers around the
| numbers and understand what worked, financially.
|
| Compare that to marketing department buying access to the same
| system in cloud via monthly subscription (let's say they start
| paying $10K total monthly - these will go to your OpEx). Any
| growth is now super straightforward to assess - you've invested
| $10K, you got 10% more sales that month, and you can now deduct
| all the combined OpEx from that number and see if you are still
| profitable after bringing the new system in. That's a reason
| #1.
|
| Accounting and decision making complexity is not the only
| reason to prefer OpEx. Note that accountants came up with smart
| ways to make CapEx behave more 'OpEx-y' - for example, this $1M
| in the books will be spread across many months or years by
| using depreciation across system lifetime, so that upfront
| investments _can be_ comparable to daily expenses. But the same
| way you are not _buying_ a local car each time you arrive on a
| vacation somewhere, businesses don 't want to have hands tied
| in large investments - oftentimes renting something is
| preferred, and business people will still call their decision
| to rent instead of buying "switching from CapEx to OpEx".
| That's a reason #2.
| count wrote:
| The CapEx -> OpEx push is also heavily tax based. I can write
| off (generally) 100% of an OpEx expense today (or, as I spend
| the money). CapEx expenses become Assets, which are tracked
| _and taxed_ , and the business doesn't get to write off that
| spend immediately - it turns into a 'depreciation' write off,
| spread over the useful life of the item (sometimes 5, 10, or
| more years). Real estate, vehicles, large equipment, etc. is
| generally all done this way - a CapEx gets you an asset or
| property, which is then taxed and depreciated. Software
| licenses, insurance and other things can also be done this
| way (CapEx), depending on the terms and your accounting
| standards.
| lotsofpulp wrote:
| > CapEx expenses become Assets, which are tracked and
| taxed,
|
| > Real estate, vehicles, large equipment, etc. is generally
| all done this way - a CapEx gets you an asset or property,
| which is then taxed and depreciated.
|
| What tax(es) are you referring to? Property taxes?
| count wrote:
| In some cases (e.g. a building or expensive equipment
| purchase, probably yes, property taxes in most
| jurisdictions, at least in the US). The depreciation is
| deducted from income for income taxes over time, rather
| than all at time of purchase as an opex expense is. This
| implies a higher income tax bill 'now', with a smaller
| deduction smeared over time.
| lotsofpulp wrote:
| > This implies a higher income tax bill 'now', with a
| smaller deduction smeared over time.
|
| I would not characterize a lower deduction for a business
| expense as taxing something. I would have assumed it
| meant a buyer has to pay an additional tax as a result of
| purchasing something.
| Mashimo wrote:
| All 3 actually. Depending on what task I work on.
|
| Sometimes the customers want a specific feature, sometimes we
| have an idea that we want to develop in the hopes of selling it
| later, and sometimes you need to work on maintenance. Which also
| gets paid by customers in our case.
| a1o wrote:
| > Maintenance is always on the chopping block
|
| I wonder if someone or someplace figured a way to make software
| maintenance and support to be better valued. It's like, it's
| reasonably easy to market and sell internally the start of a
| project and consume from some internal investment (CapEx like)
| budget to make it, but once you have done all of that was in
| scope, you delivered, it's a lot harder to keep it going at the
| same steam and get budget for the continuous maintenance (OpEx
| like). Also, why it's so hard to get promotions or market work in
| good maintenance.
| generic92034 wrote:
| Maintenance is instantly a good business case if you can sell
| maintenance and support contracts to your customers. Of course
| you will rarely find that in B2C areas, but in B2B it is not
| uncommon.
| thfuran wrote:
| Though that just kicks the can. We sell support contracts so
| everyone does a bunch of bug fixing as a matter of course,
| and that doesn't even get called maintenance internally.
| "Maintenance" is the refactoring or other tech debt quashing
| that the devs always want to do but which mostly isn't a
| priority.
| generic92034 wrote:
| Where I am working bug fixing was always classified as
| maintenance work. That is even relevant for taxes, as
| ticket processing is a different category, with different
| tax rules.
| hooverd wrote:
| I think it's because the biz types would sell the copper wiring
| from the office if you let them.
| lp4vn wrote:
| The article cleverly groups the budget in three categories:
|
| - A first one that develops a product that creates a value for
| the company in the present(sales/marketing).
|
| - A second one that develops a product that will possibly create
| value for the company in the future(research/development).
|
| - And the last one that develops a product that created value for
| the company in the past and now has only to be
| maintained(maintenance).
|
| Honestly I think that this division is a bit tautological.
| Everybody in the industry knows that maintenance project are bad
| and only are worth it if you're making a good money working in
| them. Now in practice the hypothetical division between
| sales/marketing and research/development that the author proposes
| is pretty blurry and in my opinion doesn't do a great service in
| categorizing the activity of a developer.
| zuhayeer wrote:
| Another framing of this is whether companies treat their
| engineering organizations as a cost center or a profit center.
| Cost centers suppress salaries as much as possible optimizing the
| budget. There's little growth within these companies which is why
| the zero-sum philosophy is passed down to their compensation
| strategy. Whereas profit centers encourage more and more
| investment as compounding profits come in from previous
| dividends. Growth is what powers everything, higher pay has a
| positive-sum gravitational pull on talent sustaining a flywheel
| for more profits to come in (hopefully).
|
| All the companies that pay very well such as on
| https://levels.fyi/2023/ are profit centers encouraging
| investment in talent, competing for the best across companies
| because they know its worth it. Each hire even at extremely
| competitive wages will make back their salary manyfold if they're
| successful.
| georgyo wrote:
| I don't understand our modern tech culture of saying maintenance
| is the last on the list; always getting chopped and cut; never
| getting a decent budget.
|
| In 20 years and several different companies I have always heard
| this but never agreed with it.
|
| Sure, the company wants new features to market, but the company
| also wants things to freaking work.
|
| During layoffs and hiring freezes I have seen SRE type orgs fair
| better than their R&D siblings.
|
| In only one place I worked was there this culture shift of always
| having to keep building new things and not reward maintaining old
| things. It actually shifted to that culture while I was there.
| Constant migration to new internal tools, constant depreciation,
| and half baked migration stories. After the people who built the
| product get their promotion they go off to the build their next
| portfolio piece. The new shiny quickly becomes unmaintained and a
| new team comes and builds yet another replacement. In 6 years one
| internally built tool was replaced 4 times with new internal
| tools, with users spread across all four.
|
| You can say that this was just poor execution, but in reality
| saying maintenance is not valued by the business is incredibly
| toxic and leads to self destruction.
| ponector wrote:
| Both maintenance and testing are not valued by business.
| Because you cannot sell maintenance to the customer, you only
| can sell features.
|
| From the developer's point of view maintenance also a thing to
| avoid. You cannot put a maintenance as a shiny point to your
| CV. Everyone wants to see your achievements, projects you
| shipped, and with modern technology, of course.
| generic92034 wrote:
| > Because you cannot sell maintenance to the customer, you
| only can sell features.
|
| That does not seem to be true in many B2B areas. Software
| suppliers are selling maintenance and support contracts to
| their customers. Think ERP.
| ponector wrote:
| Maintenance of your software. Can you sell bug fixing of
| your software? You can sell new features. Of course you
| will add a line to the contract about bug fixing, and put
| few poor souls occasionally to fix issues reported by vip
| customers, but it is not a selling point.
| generic92034 wrote:
| See my reply to the sibling - in many B2B settings it is
| really different.
| danenania wrote:
| Even when a company sells maintenance/support/compliance,
| the incentive is still to put as few actual development
| hours into these columns as possible, and to pay as little
| as possible for those hours.
|
| What is actually being sold is a promise, and that really
| comes from the sales department, not the engineering
| department. Once the customer signs the contract, the
| incentive is to do the minimum possible to keep the promise
| --or better said, break it infrequently and non-egregiously
| enough that the customer doesn't churn (or sue). So you'll
| unfortunately still be viewed as a cost-center at many
| companies if you're working on this stuff.
| generic92034 wrote:
| You are not considering the power dynamics in B2B. The
| customers get SLAs in their maintenance and support
| contracts, including monetary penalties. It is also a
| repetitive business. Bad experiences actually count.
|
| In my experience, if anything development
| support/maintenance is delivering too much in many cases,
| i. e. not limiting themselves to fixing bugs, but
| enhancing functions on customer request.
| v-erne wrote:
| >> Both maintenance and testing are not valued by business.
|
| It depends on the incentives I suppose - if commission and
| bonuses for sales people comes only from new sales, then
| sure, maintenance is irrelevant and will be ignored.
|
| >> Because you cannot sell maintenance to the customer, you
| only can sell features.
|
| No, that's not true at all. If sales people are properly
| incentivised to sell support contracts (their base salary
| being a percent of maintenance fee for example) then it will
| be sold like crazy. I have seen this happen at my company -
| at one point we did not need new sales to be profitable -
| just raking support contracts fees was enough to keep up
| costs and then some.
| ponector wrote:
| Support contract does not linked directly to the
| maintenance of the software you are selling.
|
| More support contract does not mean company will assign
| more resources into maintenance of software itself.
| v-erne wrote:
| If you work for people that are only extracting value and
| are making decision based on next quarter predictions
| then I can see that.
|
| This is why I do not work for faceless corporation. I
| deliberately sticked with small lifestyle business that
| values maintenance as much as new sales (as a matter of
| fact just this week I was refactoring my own, original
| piece of code, that its first version is dated by
| versions control as written 15 years ago and during this
| whole time there were clients that were paying support
| fees for it)
| nijave wrote:
| You can sell security, support, and compliance and those tend
| to be tightly related to maintenance. A product hard to
| maintain becomes a nightmare for any recurring task,
| security, support and compliance all being examples.
| SamuelAdams wrote:
| It depends on your business and your clients. Maintenance in
| the form of compliance always sells, albeit begrudgingly. If
| maintaining various compliance requirements is required (like
| DoD), then maintenance budgets are usually flush with cash.
| mcmcmc wrote:
| This is very true. I work in MSP not software dev, but
| banking/finance clients almost always have budget for
| regular hardware refresh and premium support agreements.
| And they fork over tons of cash for security auditing and
| _all_ the licensing.
| leowoo91 wrote:
| You can also price in the effort of maintenance that needs to
| be done before adding of a new feature. That may explain it
| better from the leadership perspective.
| michaelt wrote:
| It all depends on the structure of the organisation, and how
| well managed it is.
|
| Imagine an organisation where developers are adding features to
| the service, where each new feature uses $1000 of disk space
| and enables $10,000 of new sales.
|
| And imagine the sysadmins buy huge file servers, each new file
| server costs $500,000
|
| In a highly bureaucratic organisation, the sysadmins will
| cross-charge the developers for disk space, and they'll already
| have the money ready when a new file server is needed.
|
| In a well run and less bureaucratic organisation, the bosses
| will realise that $500,000 bill enables projects that will
| return $5M, so they'll gladly pay it.
|
| In a poorly run organisation, the bosses will blanch at the
| $500,000 bill because it's expensive and not linked to a
| project; the sysadmins will ask the next person who needs $1000
| of disk space to pay $500,000 for it (they'll refuse); then the
| sysadmins end up having to refuse requests and cajole
| developers into only keeping 3 days of logs instead of 7 to
| free up disk space. Before you know it, the bosses are hearing
| bad feedback about the sysadmins...
| lstamour wrote:
| ... and somebody gets the bright idea to replace the
| sysadmins with "managed cloud" and S3 file storage, leaving
| the sticker price as a "digital transformation" cost until
| they can work out the cross-org billing using an app someone
| built in their spare time to read itemized bills and re-bill
| internal budget numbers for their fair share of resources?
| Spoom wrote:
| To complete the story here, the app doesn't work because
| dependencies have changed in the meantime, so everything is
| tracked on multiple giant spreadsheets.
| jrochkind1 wrote:
| > In 20 years and several different companies I have always
| heard this but never agreed with it.
|
| Do you mean your companies didn't _act like maintenance was
| last on the list_ , you didn't agree with descriptions that
| said they would?
|
| Or they indeed did, you just didn't agree this was appropriate,
| you thought they were acting inappropriately?
|
| Because you seem to be describing environments where indeed
| maintenance was not valued by the business -- you just didn't
| like it. So to "say maintenance is not valued by the business"
| is just to describe reality, like you in fact just did.
|
| I think the common saying that "maintenance is the last on the
| list" is not meant to be a _prescription_ , advocating this --
| it's a description of what seems to happen. Analyzing why and
| if there's a way for a different approach to be better for the
| business is not something OP engages in. One would _hope_ so if
| one, like you, values things working and being high quality...
| but if very vew companies act this way, there 's probably a
| reason regarding alignent of interests...
| rmk wrote:
| Well there's "should" and actual reality. The article lays out
| the latter, pointing out that it's career suicide to go into
| bucket #3. If you are not an 'up or out' type of person, then
| _maybe_ it 's worth considering spending time in bucket #3.
|
| Of course, software is obsolete the moment it's written, so it
| could be argued that a lot of people who think they are in #2
| are probably in #3 much of the time, spending a small sliver in
| #2. However, budgets are allocated once a year or maybe a
| couple more times, so if you are in something that's
| categorized as #2 when that exercise occurs, you are still in a
| better place.
| Eridrus wrote:
| I think "maintenance" is too broad a term here.
|
| Keeping the service running to a level that customers demand is
| a high priority for everyone. Nobody wants to cut SRE to the
| point outages cause customers to leave.
|
| But I think SRE is closer to "operations" in a traditional
| company (i.e. unavoidable to provide the service), rather than
| maintenance (something often deferred as long as possible).
|
| In this framing maintenance is things like tech debt reduction,
| improving internal tools, experiment iteration time, etc, which
| _is_ often undervalued relative to product impact IMO.
| bux93 wrote:
| "Sales & Marketing" and "Research & Development" are
| categorizations you may read about in companies' annual reports,
| but "Maintenance"?
|
| I'd suggest you read your company's financial statements. You'll
| find headings like "cost of revenue" or COGS, "General &
| Administrative" and others like one-off costs for mergers. All of
| these will have different dynamics, and in each company the
| dynamics may be different.
| schnable wrote:
| I'm having trouble with this framing. The buckets only make sense
| metaphorically, but is written literally. The "laws" only make
| sense literally, too.
|
| For maintenance, if "you'll see this role smeared into product
| development" and "We give you a generous 2 days every sprint to
| take care of shit that's annoying," the budget here is R&D, not
| "Maintenance."
|
| Similarly, Growth and Developer Relation engineers are often
| (usually?) in the Product org.
|
| If these roles are actually in the R&D/Product Development
| budget, the "laws" about budget management don't apply cleanly
| enough that they can be a "law."
| jrochkind1 wrote:
| Right, I read that situation as they've gotten rid of
| "maintenance" budget altogether, because it was so de-valued --
| you won't find any software engineering jobs actually attached
| to maintenance budget anymore in such an organization -- and
| now what maintenance is done is done in the margins of jobs
| whose primary purpose is R&D, attached to R&D budgets.
| Steven-Clarke wrote:
| Re: (US) Internal Revenue Code (IRC) Section 174
|
| "The Tax Cuts and Jobs Act was enacted more than five years ago,
| but certain changes under the legislation are only now coming
| into focus as taxpayers prepare their 2022 tax returns. In
| particular, there are significant changes as to the deductibility
| of certain research and experimentation expenses, as well as the
| ability to utilize net operating loss (NOL) carryforwards. These
| changes may result in greater tax liabilities for companies and
| may also affect certain qualified small business stock
| eligibility requirements".
|
| ref/
| https://www.cooley.com/news/insight/2023/2023-04-28-startups...
| ttyprintk wrote:
| Software development costs now must be amortized.
|
| https://news.ycombinator.com/item?id=38698457
| physicsguy wrote:
| The only orgs I've not had mad stress have been research
| oriented, with the expectation that some things will pan out and
| others won't.
| SamuelAdams wrote:
| I really like this, but patio11's blog does a nice job as well.
| He breaks it down into cost centers and profit centers, and
| argues why you really want to be attached to a profit center.
|
| Lots of other good stuff in here if you haven't read it.
|
| https://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-pr...
| shermantanktop wrote:
| That's my #1 rule; go (and stay) where there is either profit
| or a realistic path to profit.
|
| Rule #2 is to play a role within that profit center which can
| be credibly linked to continued profitability. It doesn't have
| to be directly making money, but it should be clear why the
| money will be directly impacted if I stop doing my job.
| hellectronic wrote:
| Sounds like the Gartner RGT model
|
| https://www.gartner.com/smarterwithgartner/align-it-function...
| jpswade wrote:
| Historically software engineering was part of the IT function,
| which historically was born out of accounting, a computer
| literally was someone's job, before a machine could do it.
|
| Today, for many businesses accounts is still the main driver
| behind software, and also the budget.
| ConnorMooneyhan wrote:
| I'm in sales/marketing; bored out of my mind, so I'm studying to
| be in R&D.
| scarface_74 wrote:
| Amazon: "we can build S3 - a service that millions use with no
| down time. But we can't build a simple website to serve our
| internal employees come review time in April"
| scarface_74 wrote:
| > Building internal tools can fall into this category. That
| unloved admin dashboard that runs the company but never quite
| gets priority.
|
| Amazon: "we can build S3 - a service that millions use with no
| down time. But we can't keep a simple website up to serve our
| internal employees come review time in April"
| chrisweekly wrote:
| Tangent: Swizec authored a book I found very useful a few years
| ago ("Serverless Handbook"), and writes a thoughtful and
| insightful email newsletter I've enjoyed for many years. He's
| firmly in the "learn by doing / learn in public" camp, and does
| an excellent job sharing what he learns along the way. Highly
| recommended follow / subscribe.
| throwawaaarrgh wrote:
| Sales/marketing don't even exist when a product is first being
| built, but you're getting paid... but your salary isn't R&D. The
| pace isn't calm. The stakes are high. The target can pivot
| violently.
|
| Your salary is coming from the Business Plan's Capital
| Expenditure, as part of an initial round of investment needed to
| achieve the Business Goals. This is a marked difference from
| Operational Expenditure, which "Maintenance" is most often lumped
| under.
|
| Whether your salary is CapEx or OpEx has a much larger impact on
| your ability to work freely and productively than what of these 3
| (really 4) categories are.
| prepend wrote:
| I think a better way to think is as product development. Sales
| and marketing exist from the beginning even though nothing is
| being sold yet.
| prepend wrote:
| I remember early advice in my career to always work for a revenue
| center not a cost center.
|
| This was really helpful as having something that makes a firm
| money seems more easy to measure impact than a cost center.
|
| The natural incentives seem to jive better. Revenue centers are
| supposed to increase and are a function of margin. So more
| salaries and expenses should lead to more revenue. Cost centers
| are supposed to decrease or stay the same. So always a pressure
| to cut expenses.
| paxys wrote:
| No company I have ever worked for has had growth engineering
| salaries come out of the marketing budget. And there's no such
| thing as a "maintenance" budget either. It is all simply
| R&D/engineering. Sure the expectations are very different
| depending on your team/role, but that's not a budget thing, and
| depends on how the company tracks its goals.
| SkyPuncher wrote:
| These budgets aren't often labelled as explicitly as the
| article states, but I've found they're generally accurate.
|
| You either make money now (sales), you build long term value
| (product), or are circling the drain (maintenance) on an
| existing product.
| paradite wrote:
| I think the budget is used figuratively here to mean where your
| contribution / value-add to the company is.
| osigurdson wrote:
| As an aside, it seems that the $500K/year jobs have dried up - at
| least I don't see much of that on the "Who's hiring". Salary
| ranges seem to be more in the $100K - $200K range.
| angarg12 wrote:
| I'm in FAANG making close to that, and I have been testing the
| market for a few months. I found less than a handful of
| companies that could beat my current comp.
|
| The vast majority of companies I've talked to seem to top
| around 250k even for Staff+ roles.
|
| The author says that EU ain't no Silicon Valley, but 2024 sure
| ain't no 2022.
| closeparen wrote:
| These compensation packages served the very specific purpose of
| enticing US-based talent to relocate to the Bay Area. As we
| increasingly accept remote work for senior talent and look
| abroad (or not at all) for junior talent, this is not as much
| of a need anymore. The inflow to the Bay Area always had a
| built-in expiration given there are only finitely many
| neighborhoods to gentrify and still no appetite for significant
| housing growth.
| __turbobrew__ wrote:
| I think the ceiling is still there where if you have special
| hard to find skills (ML and distributed systems at my company)
| you can still command that salary but if you are just writing
| crud apps nobody is going to pay you half a mil per year
| anymore.
| irrational wrote:
| What about HR? HR Tech is not working on software to create new
| products (research and development) or on software to sell said
| products to other people (sales/marketing), but it also isn't
| maintenance.
| patja wrote:
| The whole blog post is very tech company product oriented and
| seems almost completely oblivious to the vast number of
| software engineers building line of business applications for
| internal use, under the COO's budget.
| OJFord wrote:
| Maintenance is a bad word for it, but the author clearly
| intends it to be in that category:
|
| > Building internal tools can fall into this category.
| uticus wrote:
| Very closely related, this comes up on HN from time to time:
| "Don't Call Yourself A Programmer, And Other Career Advice"
| https://news.ycombinator.com/item?id=3170766
| indymike wrote:
| There are actually four buckets:
|
| 1. Research and Development. Special tax treatment and tax
| credits usually apply to R&D.
|
| 2. Sales/Marketing - Pre-sale sales engineers, sometimes
| implementations
|
| 3. Maintenance. Developers that fix bugs and perform non-R&D work
| on code that usually isn't eligible for special tax treatment or
| credits.
|
| 4. In hosted services/PaaS/SaaS, operations usually carry some
| level of swe salaries.
|
| Understanding the tax implications of which budget and what work
| is being done is really important, and gets much more complex as
| you grow.
| MichaelZuo wrote:
| There's also a fifth bucket for really large companies and
| really high end engineers:
|
| 5. CEO/COO/CTO's special budget for special consultants
| phkahler wrote:
| >> You're only as good as the multiplier a company gets on
| pouring money into your bucket.
|
| Well that's why some places have sales people on commission. You
| set a fixed multiplier and let the sales person do their thing.
| You can still offer bonuses, but if one guy makes half the sales
| as another so what? He automatically gets paid half as much.
| Software supporting multiple sales people isn't so individualized
| though.
| GCA10 wrote:
| The analysis of maintenance budgets is depressingly accurate.
| Especially as tech companies get older (and they age surprisingly
| fast), it's quite startling to see how most of them become
| organizationally indifferent to various small to medium glitches
| in established products.
|
| I can see why a lot of people working in tech will focus
| weekend/break energy on side projects (woodworking; solo sports;
| playing in a band) where exquisite craft is everything.
| tonymet wrote:
| It's also important to understand the business of the industry
| that you are in.
|
| Many are judgmental (even within this thread) of some companies
| not "valuing" software engineering. It's naive to compare social
| media companies that are making 70% topline margins to auto or
| airlines companies that are making ~ 15-20% . Of course one
| industry can hire more engineers, pay them better, give them more
| swag & benefits.
|
| Even within companies, some product lines and functions will be
| receiving long term investment. Some product lines may be higher
| margin than others. There will be a big difference in the money
| available for software products depending on the budget.
|
| I encourage engineers to consider their business' finances when
| thinking about their job. The company is not a charity or a
| church -- it's a business with cash flow, revenue & a long term
| strategy that all has to be balanced with the cost of building
| the product.
| giantg2 wrote:
| My salary comes from _Arachis hypogaea_.
| shadowgovt wrote:
| It's important I think to note the head fake that Google's
| engineering pulled off when they developed site reliability as
| its own discipline.
|
| It's maintenance, but the argument they successfully sold to
| management was that if management planned to scale indefinitely,
| maintenance cost would also scale indefinitely _unless
| maintenance also had a budget for R &D_ to push up the ratio of
| services maintained to maintainers (and the authority to tell
| software engineering "Yes, you built a new shiny thing, but it's
| not shaped correctly yet to be maintainable so here is the pager,
| enjoy your 2:00 a.m. wake up calls to keep the money flowing").
|
| This has, overall, worked pretty well for them given what they
| want to do. While maintenance is still a cost, it's understood
| that they minimize that cost via R&D, not cutting.
___________________________________________________________________
(page generated 2024-01-04 23:01 UTC)