replyifuagree

McDonnell Douglas knows they can continue to drain Boeing of money because the US govt will step in to bail Boeing out when things go really bad.

Reminds me of the cynical calculus around power companies here in California.

Came here to post this!

Yep, Tim Cook is a pretty amazing at operations. Creative leader of creatives though, he just isn't that.

I covet that guys job big time. However, I'm actually too busy playing factorio to do his job so there's that.

I just went with it and enjoyed the visual!

Many human engineers get happy chemicals from helping people! Also many humans!

lulz @ facebook revenue breakdown

>it sends all the right signals

Wow that just drips frat house product manager!

Did Mayer really just spend two years professionally coding before becoming a product manager?

If true, that smells like a root cause for how bad Mayer is at running tech.

There is a proven relationship between contacts made and sales made. Which is why sales managers constantly push sales staff to be making calls. Sales has been around for way longer than development, the underlying theory for sales is well known. Just like the underlying theory for manufacturing is well known.

Yes it is.

lol, I'm just thinking of how awful the Manhattan project would have turned out if it had half the invisible things that can go wrong in software deployments.

If software caused mushroom clouds each time it had a problem in the field, nobody would let MBAs run software projects!

>if there was some way of estimating how long software tasks would take, software companies would hire a professional estimators

That's awesome. In my feistier days I would have used that at work!

That entirely depends on whether or not the team is making something that is going to fulfill an unmet market need.

If they are in the majority of developers being mismanaged to crank out software that nobody wants, then have them code in an open office space with bullhorn wielding circa 1890s speed bosses yelling at them to type faster. It really makes no difference as most legacy business teams shirk their responsibility to get out of the building and figure out the real needs anyway, so might as well let the devs work on their craft until a real opportunity to make a difference comes along.

But 100 phone calls will, there is actually no such relationship in code - in fact deleting code significantly reduces liability, I guarantee reducing sales calls will not have the same effect.

Integrating VBA into excel was an interesting one as the excel team refused to just pull it in as a dynamic dependency but wanted it embedded straight into the deployment to avoid the DLL hell that was common on the windows platform. In addition going from having no automation via something like VBA to having automation required some pretty complex work.

As for the Manhattan Project, you might want to think on the difference between the words complexity and difficulty. And then you might consider that when working with nuclear material to create the world's first nuclear bomb, you would want to keep the complexity as low as possible, sheerly out of self preservation.

You forgot elk dinners at nice restaurants! I'll never forget when CA threw everyone parties to celebrate the sale of software the company couldn't use.

P.S. Not really, you covered it nicely under fraud

Not really, the shotgun approach actually works with sales - especially if the sales force has been slacking and not chasing leads.

Whereas with code, deleting code and writing less code is very much preferred because each line of code written increases the complexity and risk in the system.

This is why business teams who are shirking discovery and instead focusing on the anti-pattern of trying to increase engineering productivity is such a massive mistake. Not only is the team pooping out code that doesn't fill a need (and hence won't be monetized), but they are also rapidly increasing complexity and opening the business to future liability when the code causes customers to seek remediation.

The quarter driven nature of most companies amplifies this bad behavior. This is why we see this revolving door of executives who come in, drive some bad initiative to incompletion, declare success and move on before their chickens come home to roost.

If we consider that Fungibility is on a continuum of very low on the left and very high on the right. Where do you think most sales fall on the continuum?

I'd claim that businesses are biased toward chasing a highly fungible sales model, to the point of eliminating the need for a salesperson altogether, and so naturally sales tends to the right.

If you are like most business people I've worked with, you love my complicity.

I promise you what you are experiencing is a management problem, not a dev problem. Devs absolutely love executing on creating easy to code software solutions to well defined problems. Many of us will work the weekend on that kind of work just to get the dopamine rush.

Your are correct in the majority of places where developers work. And this is simply because most developers work under legacy management where they are siloed off from the business - so typical Machiavellian silo on silo violence is employed to get one silo to commit to the desires of another silo.

It's crazy because the customer gets totally hosed by bad software implementations, and if good working software is actually important to the future of the business, a slow march towards bankruptcy happens.

>Only work on the project half the time, spending the other half on something more worthy/interesting.

This is actually a pretty common motivation for devs who work under legacy management.

>be very careful that you don't make this approach the standard way of working

Legacy management steeped in manufacturing has entered the chat!

Yep it is very unlikely that the business silo has a clue what needs to be built.

Regarding open offices. The Fed commissioned MIT to do a study on the effect of public observation and found that it significantly reduced people's effectiveness at solving puzzles.

Because you'll figure out how to crunch enough tickets for a minivan!

https://devhumor.com/media/dilbert-s-team-writes-a-minivan

One thing to watch out for is confusing IT work for dev work. I see this a lot with business folks.

An example of IT work is installing MS Office on a laptop by hand.

An example of dev work is integrating VBA into excel so that office users can automate excel using VBA.

Meteorologists also don't put themselves in my shoes when I ask for sunshine.

And you'll be happy to know that these days I suss out the estimate the business team wants and give that estimate. Then carve out more time via scope exceptions. Then, because I can't carve out enough time to actually finish, deliver a release that looks finished to a QA team, but is actually riddled with customer operation interrupting performance problems, intermittent crashes, memory leaks and bugs.

Here is the very best part, the business team blames QA for not finding the problems.

Yep, these days I tend suss out the estimate the person is looking for because the relationship is actually more important to my career longevity. I mean, the estimate is very likely wrong anyway, so they might as well be happy for a bit!

This works because almost never is the true scope of the work known when the ask is made, so it is usually pretty easy to say later "hey, blah blah blah wasn't taken into account for the estimate." Having a good relationship from step one makes it pretty easy to carve out the extra time.

There are some more lizard brained people who play hardball, but as long as I was nice in step 1, my VP handles them. Not sure what I would do if I didn't have a decent VP!