In my experience it wasn't the excess employees (everyone seemed to be busy) but that processes in the org didn't match the size and leadership from the top down couldn't see the problem. So no efforts were made to make teams work better together and align their incentives.

A great example was API teams would ship incomplete and untested work as "done" because they were overworked and on an insane timeline. My front-end team tested the APIs for implementation and discovered all the missing parts, and then we had to document all of it and ask the team to fix it. The API team would then push back claiming we were wrong. My devs would have to spend hours on calls with them going over each missing piece and the API devs played dumb every time.

I would have to escalate to my manager and he felt pushing back on the other leads would burn political capital he didn't have. This wasn't just one API team, it was seven. Somehow the culture of the org caused them all to follow the same strategy to push their QA to other teams and delay completion. It was so crazy that they would get defensive saying "we have the best developers in the world, that is not possible."

A true organizational illness.

In sensible work environments, that's solved by aligning incentives at project level. If your frontend team crucially needs something done, but the backend can't give a shit, the problems run deeper than area of responsibility IMHO. Either what the frontend works on doesn't matter, or the backend team wants to sink the ship, or there's way too many fires to put out and the ship is already sinking.

Having mega teams or filling them with jack-of-all-trades types also has critical downsides.

The simple result I get introducing the concept: https://medium.com/mobilepeople/backend-for-frontend-pattern...

If there is only one front end that talks to the back end, then yes I agree. If there are 20 different front ends from 20 different teams, some of them external, that are expected to talk to the same API, then it makes a lot more sense.

In other words, have a team with front and back-end devs working together, with a frontend acting as a sensible default interaction to an API. This can be something as simple as a widget or component.

This front end is expected to have a full suite of tests running through the API (or an api test device -- this test device can also be used to better communicate the requirements to backend devs), and be well documented in how and why it's doing something.

That acts as an example for any other frontends. When they have questions or issues with the api, it also provides an immediate source of truth to show how to properly do something. And it provides confidence that the API is behaving in the expected fashion for the user experience being provided for.

Just a thought.

In one project we were rebuilding an old outdated UI. We started with being very strict about literally only implementing what was needed for frontend, for example not even a GET /widgets/{id} until there was a UI that needed it. We also explicitly built new models for this, separate from our database models, so it wasn't just "return everything in the table": if the UI only displayed half the fields, that's what was returned. A big benefit of this mindset was when we needed a list of things from joining multiple tables, there was no thought of pushing this to the front-end; we just made a viewmodel, did the work server-side and returned it.

Also, pretty early on we implemented Swagger (OpenAPI) and built in docs to our code. This helped establish it as a part of dev and the coding style that any new devs quickly bought into, as opposed to an afterthought everyone sees as a chore.

After we had a a dozen or so APIs done, we started opening it to customers. We'd add new things they'd request (but our UI didn't need), but strictly kept the use-case-first mindset, as well as continuing the UI port (page-by-page, effectively). Even a few years later, the feedback from our developer users was overwhelmingly positive, along the lines of "this is the best API I've ever used".

I work on a small team (2 backend devs, 2 frontend). The we are always arguing about the API. The frontend devs want the data for their components pre-formatted in 1 API call. The backend team wants to run a SQL query and return the entire record as JSON.

Likely scenario: backend formats data and moves on / gets busy elsewhere. Frontend changes, so that data is now required in a different format. Frontend decides to just reformat it at their side because of schedules. Now it’s a mess and nobody knows why.

The root of the problem is this stupid frontend/backend team division when it’s actually a single program. That’s where the idea of “let’s ask fullstack” comes from. But there’s no good answer this guy could give you, apart from “stop drawing stupid dividers across the whole”.

That was obviously a really general rule of thumb not intended to be an actual architecture guideline...

Or just use GraphQL-esque methods, but versioning will poke its head in somewhere eventually.

Don't get me wrong, I quite like Java and the good tooling, but I'm more exposed to C# these days and Java feels like 90% the same, so I'm never compelled to go back.

Or you are maybe sarcastic, impossible to tell in text...

Side-edit: from the very beginning, Java was simple, when it was released. But in 2010 it felt super confusing to me.

That coming from experience of managing various shit turborchargers like tomcat or jboss that just added tons of unnecesary complexity and zero benefits to 90% of apps that used them

LifeRay, not even once.

Is it? I come from a very different background and I'm trying to get a small Java back-end up and running (Quarkus) and wow, it's so painful! There's a huge amount of buy in, to me, in the framework. I found Node, Go and Python to be easier in simply delivering a HTTP(S) server. I've gotta do it in Java for reasons.

const app = express()

app.get("/user", (id) => { return db.user(id); })

app.run() or something like that.

Spring is just a few annotations away from creating an endpoint.

https://start.spring.io/

Of course with spring, there’s a lot of stuff that isn’t java that you have to know.

However, the Spring framework in the 2000s was a horrible mess of "aspect oriented programming" and obscure XML configuration files. Till this day I had no idea what it was trying to achieve with that architecture (except maybe trying to avoid writing code by writing lots of XML configuration files instead)

I think they learned their lesson.

There does need to be oversight over whole thing to avoid exactly what is described above.

Nope.

“We have to show progress!”

Other parts of the org like UX and product need to fulfill their obligations as well or it won't work. I've found a lot of teams deep into a death march who never bothered to push product on incomplete requirements.

Whenever United Airlines decides to do something about the pilot shortage by paying for flight school (not just 10% of it) I’m down…

I wrote them a cover letter that began:

- - -

When I design an API, I start with the apps. An API has no value on its own; its value comes from what you can build with it.

There may be an existing app that needs a new API feature, but I like to write a self-contained sample app for quick iteration on the API design and to include in the SDK.

An API also needs full test coverage, of course, but that comes after this initial step. Instead of test driven development, you might call it app driven development.

An SDK developer is also in a customer support role: they should write solid reference documentation and tutorials and sample apps, and interact directly with the users of the SDK. It’s not a job for someone who likes to just sit quietly and code.

One of my hobbies has always been to assist other developers in various online forums. Most recently this has been on Stack Overflow where I’ve posted over 600 quality answers. Previously I was known for my advice on the original jQuery mailing list and Windows programming forums.

- - -

I went on to list some of the APIs I've built.

The cover letter must have resonated with them, because they brought me in for interviews the next day, and made an offer the day after that.

This looked like my dream job! I love building APIs, working with the developers who use those APIs, and especially anything to do with geospatial data.

The team that hired me had been a startup that was acquired by a larger company in another state.

Things looked great at first. I was writing sample apps and imagining what APIs would make it easy to develop those apps.

And then a team of Architects from the larger company swooped in and decided that they should be the ones to design the new API.

They liked to design with UML charts of boxes and arrows, and thought the API should reflect the inner workings of their system.

I thought the API should be simple and easy to use for outside Python developers, and I tried to put myself in the shoes of those developers to understand what would make their jobs easier.

At one point my manager asked, "can't you just implement what the Architects have specified?"

I gave it my best, but by that time I was demoralized and unproductive. The company wanted me to do the exact opposite of what I was good at and what they hired me for.

I was fired after three months.

I've had to create and consume these type of APIs. Demoralized and unproductive has always be the result I've gotten.

What strikes me as interesting here is the interference levels. The big question I have here is my initial thought upon reading this is: When the parent corps software architects came in to lay claim to the new frontiers of their acquisition, a few common scenarios come to mind [0][1]:

The first is that its entirely possible that the architects saw a greenfield way to grow their career by treating the acquisition as a chance to grow their stature. Therefore, its important for them to have their names all over things and for some understandable version of what gets done to mirror things others will understand, presumably so they have the easiest path to explain their OKRs (or similar). If this was the case, then the best thing you could have done in my view was to express early about collaborating and learning their process, and try to insert yourself into the discussions and appeal to them as an authority, while selling your idea as if it was their idea[2]. The metric for them is visibility, familiarity and career ascension, and thats the hidden goal in this scenario you have to play into.

Another scenario is that the team had already largely sold this upstairs (or it came as a top down directive) and they were simply under the thumb of need to make this follow the same uniform structure that the team had been following without any real room to make exceptions. It'd help if people just said this, but I have found often they don't, it comes out in other ways. A key thing I like to do when I interact with a team and they present me with something before I'ved asked for it in detail is ask if they already started or got some kind of sign off on it. If they did, you can appeal for changes, accept the design as is, or appeal to the higher stakeholder involved. In these situations, I've had the best luck drilling down into the surrounding circumstances and figuring out who it is that I need to build a relationship with to change the circumstances for the better, whenver possible. These are more political in nature and really will reveal alot about culture, so its important to use a deft hand. I've been in situations like this, and I've usually pitched something to the effect of you don't want this acquired tech to go south, perhaps we should re think this before it becomes a larger problem (though decidedly not worded in this direct manner, again, use a deft hand)

Lastly, the last scenario that comes to mind for me is that its entirely possible that the team was generically tasked with taking on architectural responsibilities post acquisition and they simply had different culture / methodology for handling this, and only an appeal to a higher authority or diving into their existing process would help at all. I find generally its best to see if you can get into their process and start to form things around how they're already working that move the needle rather than trying to wholesale push back against whatever it is they're trying to achieve, that usually ends up being a losing proposition unless you have higher authorities vested in your success and outcomes over theirs, basically.

[0]: They're hypothetical and based on what I've seen and learned from others, but not representative of every situation, and may not be related at all to yours.

[1]: The advice I may lay out here, is hypothetical in that I can't speak to any specific situation, only pattern match. Sometimes, politics kills any good intent and attempts at proper compromise. That's when it becomes a red flag, depending on how, what, why, who and how often. can't win them all, unfortunately

[2]: I realize this is one of the tenants from books like How To make Friends And Influence People but its easier than you might think, if you haven't done it repeatedly it might sound sneaky but it boils down to agreeableness to a big degree.

Very difficult in practice, does anyone have stories on accomplishing this in a developer job?

If I need to insert myself into a discussion I play dumb by asking a lot of questions even if I have knowledge/experience with the subject. To present alternative ideas I'll ask things like "Why wouldn't X work here?" or "What are the benefits of doing {current thing} instead of {what I want}?". Since I'll already have knowledge of the subject I can mostly tell when their responses don't make sense and I'll continue asking to follow-up questions trying to get them to see things from my perspective. I've done this a lot and it seems like it's a 50/50 shot that they'll be open to trying your ideas.

Find people who can do both, or create cross-functional teams that can ship things somewhat independently

Wasn't there some design document which had some of the acceptance criteria or the requirements?

I work in a small company, 3 or 4 devs, couple business ops guys, sales guy and head of company.

Even I decide sometimes "naw I'm just making the call on this so it is consistent and works" and don't bring anyone else in on things because it is time to just make a call.

At a big company, I can't imagine the scale of human involvement in every decision... just takes one idiot to gum up the works too.

We're working with one company now who is paying through the nose because we keep having meeting after meeting about the same things over and over and this company has a "meeting terrorist" (my term) who is absolutely determined to bring up the decisions from last meeting to start every meeting and re-debate everything for no reason at all. It's madness.

That's an actual sabotage technique advocated by the OSS:

"Refer back to matters decided upon at the last meeting and attempt to re-open the question of the advisability of that decision."

https://en.wikisource.org/wiki/Simple_Sabotage_Field_Manual/...

He even raises the prospect that there are other people (never mentioned) who has concerns about his own idea ... and he's the only one to bring those issues up, and argues against his own ideas.

Dude is either incompetent to an insane degree or straight up sabotaging the company.

I met a project manager like this on a client implementation a few years ago.

The client felt they needed 7 phases (requirements gathering, analysis, design etc. etc.) - this is for a SaaS product but whatever!

They also felt there were 8 business areas that each needed to be treated separately (support staff, retail, warehouse, etc. etc.).

So the day after we signed the contract I came in to find my inbox bulging with 56 (i.e. 7 x 8) two-hour meeting invites from the meeting terrorist. There was one for each combo of phase and business area - e.g. a two hour meeting for requirements gathering for the support staff area, another for design for the warehouse area, and so on. There were no delays between phases.

Untangling that shitfest did not start the project out on a good footing.

It’s somewhat intentional. They want the manpower to make big moves, but don’t actually want to shake things up.

So you put red tape all over the place and start games of phone tag with a dozen teams.

And god help you when people establish polices just because they imagine something might happen.

In these emails it looks like managers/execs are trying to figure out how they could/can beat apple. My answer: get out of the way of the highly talented people you've hired. The business aspect is only possible with a technical solution people like (not zune!). MS has many products like that that feel like a committee of managers designed them and really smart engineers did their best to overcome those decisions (until the last few years at least).

Making the guy who wrote sysinternals (got shit done despite MS) as head of Azure is one if their best decisions. Not that Azure is the best but it is definetly very usable and very popular with enterprise customers.

2. One who are good at maintaining the existing product and are so scared of breaking the boundaries that they often add roadblocks to first category people.

3. People who don’t know jack, and are effective at management, politics and rest and vest.

Often at FAANG, being the beast that they are, the leadership is filled 2nd and 3rd category people. Perhaps that is why you find them good at keeping the lights on, and they satisfy the 1st by buying out the competition.

I, not hyping myself consider to be of first category, but I found going down this path of carving out your ideas is extremely hard. The people at leadership, management are extremely good at politics and portraying themselves bigger than they are. As a result, you need either lot of eng and support team to build anything, or find your way out to develop things on your own and get bought back into FAANG.

1. During the time in question , Microsoft was by far the dominant tech company, Apple was just coming out of being “beleaguered” and the iPod was just becoming popular. Facebook didn’t exist, Amazon was thought to be a money losing company months away from bankruptcy, Netflix (which shouldn’t have ever been considered BigTech) was worried about being crushed by Blockbuster, and Google was far from dominant.

2. The original acronym coined by Cramer was “FANG” and left out Apple completely

3. By todays standards, when people talk about FAANG they mean BigTech - Microsoft has been one of the top 5 most valuable companies since 2000. As of right now, Netflix ranks 115 in the F500.

It's MAMAA now

Then, they themselves became the big bloated companies they once beat.

This article is 20 years old.

The same could be said for Steve Jobs. Since he has passed, the company seems to be losing its focus (It was sometimes focused on the wrong things, though, when he was at the helm). I think that a certain other, tyrannical CEO may be a good/awful example...

Not to overly critique but the iPhone and iPod were 'top down' and Zune, etc were the way you're describing. So Apple pulled it off