Live data from Hacker News

Maximizing Developer Effectiveness

martinfowler.com

81–90 of 168 posts

Re: Maximizing Developer Effectiveness

#81
post #51

Here I am, a productive developer eager to deliver maximum value to my customers and apply my innovation to company goals. Open up JIRA and pick up a unit of work to produce today -- gotta stay faithful to those story points! Somehow, a magic team of spherical devops in a vacuum created an environment where things are just green, predictable, and are never broken. Another theoretical team of angels from a parallel un…

It is true that the effective developer environment sounds a bit too good to be true. Also, there seems to be a contradiction in it. We get an answer from the other team very quickly but on the other hand there are no interruptions. It seems a bit hard for both of these things to be true at the same time. On the other hand one does have to notice that one can either be moving towards the effective developer environment or towards the ineffective one. It is a very important question in which of these two directions the actions of the team are headed. E.g., if the nightly build fails is somebody doing something about it or not?

Re: Maximizing Developer Effectiveness

#82

Earlier quoted context omitted.

Clear boundaries on multiple levels as well. I believe a _very_ big part of why people feel they need microservices is because of poor architecture and a lack of boundaries in a monolith. Every single monolith I've come across has had issues with circular dependencies and no real contracts between "apps" (as they are called in Django). I believe people see ORMs such as Django's as a way to perform one big query as op…

But then why not just introduce a rule: Django ‘apps’ can only talk to each other via pure Python dicts like an interface? (rather than sharing models)? This situation is a necessary conceptual step before decoupled micro services and far far easier (because it introduces none of the ops problems of microservices). But that never seems to happen. I think it’s because codebase discipline rules are harder for managemen…

> But then why not just introduce a rule: Django ‘apps’ can only talk to each other via pure Python dicts like an interface? (rather than sharing models)?

1. One person or group needs to decide on what the rule should be, what the boundaries are and how to enforce those boundaries. This is usually not an easy process, ymmv.

2. After a decision is made, you'll have to decide on how to put the rule in place. Are you going to stop everything and make sure all code paths are working according to the new rule? Are you going to do it incrementally? New features = new rule, old features = common sense? Another variation?

3. You then start running your new rule and maybe you enforce it with some custom static checks, and when that fails you hope your code reviewers will always catch this every time.

4. You still need that one person or group to make sure this actually gets done and to assess if it actually has a positive impact on velocity and reliability.

Or you can put in an implicit "rule" that new code happens in a separate repository, where you don't need to care. A developer that has to do an API call because they simply cannot "import" another module or "query" someone else's data has no choice but to do the right thing - though many opportunities to do a lot of other wrong things too, this is not a panacea. But when we're talking about more than ~5-6 teams, the coordination effort of making sure everyone is aligned on a monolith can be much tougher than to go to multiple services (hopefully not micro).

Re: Maximizing Developer Effectiveness

#83
post #51

Here I am, a productive developer eager to deliver maximum value to my customers and apply my innovation to company goals. Open up JIRA and pick up a unit of work to produce today -- gotta stay faithful to those story points! Somehow, a magic team of spherical devops in a vacuum created an environment where things are just green, predictable, and are never broken. Another theoretical team of angels from a parallel un…

This reminds me of this wonderful piece of art from Krazam; The Hustle. [1]: https://m.youtube.com/watch?v=_o7qjN3KF8U

Why haven't I seen this before?

Why am I on Hacker News at 1 in the morning on a Friday (Saturday?)

Re: Maximizing Developer Effectiveness

#84
post #60

Earlier quoted context omitted.

I'm going through this right now. I'm helping a customer deploy Azure App Service (similar to AWS Elastic Beanstalk). Jesus wept. It's sooo fiddly to set up everything. The prod and non-prod environments need dozens of parameters that are all slightly different. Some of these are exposed as resource properties, making them obvious, some are environment variables that are nearly undocumented. Everything is off by defa…

Things are not perfect anywhere but Azure is a bit of a special case. It seems optimized for unskilled people being able to stumble in the right direction by using IDEs and clicking in portal; not for efficiently streamlining development processes. ARM system in particular is deeply broken in so many ways. All cloud providers could have been a lot better but Azure is worse than average. (Yes I have to usw Azure a lot…

Conceptually the resource manager part of ARM is actually fairly elegant.

The implementation on the server-side is a bit messy. Things like read-only properties being mixed in with read-write properties, and internal code-names used for final production systems.

Then the actual client-side tooling is a disaster. The ARM template language is just raw JSON, but isn't case sensitive and includes comments and a bizarre expression language. It's very weakly typed and then even ignores the weak typing that it does have. I've lost count of the times I've been forced to put a number into a string because... reasons.

They're working on a replacement language called BICEP, but IMHO they should have gone down the same path that Pulumi did.

Re: Maximizing Developer Effectiveness

#85
post #51

Here I am, a productive developer eager to deliver maximum value to my customers and apply my innovation to company goals. Open up JIRA and pick up a unit of work to produce today -- gotta stay faithful to those story points! Somehow, a magic team of spherical devops in a vacuum created an environment where things are just green, predictable, and are never broken. Another theoretical team of angels from a parallel un…

I belly-laughed for a good while after reading this, thank you!

I have had jobs ranging from entry-level phone tech support to Silicon Valley FAANG (E5 equivalent) to "the ops guy" at a New York startup. Like many here, I've been doing "DevOps" since before the term existed. Every job will have both kinds of day as described in the article. The only thing that matters is the ratio of good to bad, and how much you enjoy your work, your boss, and your coworkers.

Re: Maximizing Developer Effectiveness

#86
post #54

Earlier quoted context omitted.

Liked your post, do you have any reading recommendations on the subject?

+1 excellent advice, please take the time to add references if you can.

I would really like to, but some of these references are papers I had come across a decade ago, so it would be difficult to track down. I don't research this stuff formally, it's just something I like to read up about.

I did manage to track down this New Yorker article: https://www.newyorker.com/magazine/2007/12/10/the-checklist

I know it's not exactly Nature, but the point made stands, and I did track down some papers related to error rates and different methodologies used to reduce them. There's a reason surgeons and pilots both use checklists. It's because a failure of quality in their profession kills people.

Lives don't have to be at risk for quality to matter!

Re: Maximizing Developer Effectiveness

#87

Earlier quoted context omitted.

I'm going through this right now. I'm helping a customer deploy Azure App Service (similar to AWS Elastic Beanstalk). Jesus wept. It's sooo fiddly to set up everything. The prod and non-prod environments need dozens of parameters that are all slightly different. Some of these are exposed as resource properties, making them obvious, some are environment variables that are nearly undocumented. Everything is off by defa…

Azure product teams could do with a bit more customer obsession IMHO. And not just the existing customers you’ve had for 20 years with stale IT departments

I recently opened a bunch of support tickets with them because core product functionality is either missing or broken.

For every ticket they've come back with: It is like that by design, go complain on the feedback forums.

Like the other 10 people that also had the same issue and did complain? Their "feedback" was marked as rejected...

Re: Maximizing Developer Effectiveness

#88
post #61
post #51

Here I am, a productive developer eager to deliver maximum value to my customers and apply my innovation to company goals. Open up JIRA and pick up a unit of work to produce today -- gotta stay faithful to those story points! Somehow, a magic team of spherical devops in a vacuum created an environment where things are just green, predictable, and are never broken. Another theoretical team of angels from a parallel un…

Thanks. This summarizes and completes perfectly the ThoughWorker bingo. They are always dreaming about the ultimate factory line for knowledge workers, but they don’t get much done other than blog posts.

Last year I got to work on a codebase done from scratch by ThoughtWorks India, it was a convoluted piece of shit anywhere you looked... and, again, it was from scratch, they made a 1 year-old codebase feel like a giant ball of legacy spaghetti.

Re: Maximizing Developer Effectiveness

#89
post #51

Here I am, a productive developer eager to deliver maximum value to my customers and apply my innovation to company goals. Open up JIRA and pick up a unit of work to produce today -- gotta stay faithful to those story points! Somehow, a magic team of spherical devops in a vacuum created an environment where things are just green, predictable, and are never broken. Another theoretical team of angels from a parallel un…

Your reply is fun to read and I really enjoyed it. Of course the descriptions of the "typical day" in the original blog post is idealized. I suppose this idealization is there to make the contrast between the highly-effective day and the low-effective day. That is just the blog post.

Leaving aside this funny idealization and its comic interpretation of the blog post, in real life there are good habits and bad habits that can make a team work more efficiently and less efficiently. I have had first-hand experience with developers from ThoughtWorks, the consulting company behind that blog, and I can tell that they are indeed trying to apply those principles and strategies in their projects.

The fact that they are a consulting company gives them an advantage when trying to apply these principles. They only need to worry about the "small picture" of the project they're consulting on. They don't have to deal with all the "big picture" issues that might affect the employees working within the company they're consulting for (e.g. company politics, technical legacies, etc.) So IMHO perhaps some of these techniques and strategies to become a more effective development team are less applicable if you're working in $BIG_CO rather than in $CONSULTING_CO.

Re: Maximizing Developer Effectiveness

#90

> I often help engineering organizations that are in the midst of a transformation. This is typically both a technology transformation and a cultural transformation. For example, these organizations might be attempting to break a core monolithic system into microservices, so that they can have independent teams and adopt a DevOps approach. It's amazing this fad of microservices still hasn't subsided yet. It is the ba…

I haven't found many articles from respected sources that will convince management that microservices are a bad idea. There's https://martinfowler.com/bliki/MicroservicePrerequisites.htm... , but this won't convince them.

What I really don't get about microservices is the performance aspect. Like cache Sure, you can run them on the same box, but it's very easy not to, and I imagine that this will absolutely crater performance (at least in the DS/ML stuff I do).
Post reply on HN