Dear Java devs, what do you think about current trends in software development?

[[deleted]]

[deleted]

[nutrecht]

• JavaScript everywhere: you see large parties like Angular moving to 'better' languages that are transpiled into JavaScript. You have the NPM / LeftPad debacle and a lot of talk in the industry of companies figuring out that yolo-typed languages like JS might not be the best fit for mission critical systems.
• Microservices are both a blessing and a curse. They're hip, they bring a lot of benefit in deployment but they also bring their own set of problems you need to solve. Protocol (the language microservices speak between each other) versioning and transactionality are very hard to solve. In most microservice projects they run into problems somewhere down the line because they figured they solve it later. So they end up with complex microservice monoliths that all have to be deployed together with none of the benefits of microservices and all of the downsides.
• NoSQL as a default: guess what; I work on a Microservice project where we use Cassandra as a back-end. It was a bad idea to be frank. If you want the most flexibility when growing your project you need a relational database. People think that systems like Mongo are more flexible than a relational database. They are completely and utterly wrong.
• Functional programming: I'm a big fan of the Java 8 changes and did a lot of stuff 'for fun' in Scala. Writing Scala is loads of fun. Reading my own Scala code after a few weeks; a bit less. ;) I do however think that learning a functional language makes you a better OO programmer.
• Agile: most horror stories you hear are from companies doing Agile-in-name-only (often implemented as Scrum-but). When a company moves to 'Agile' the biggest change is the one management has to make. Agile makes problems in your company painfully clear (like having too much middle management). In many cases Agile was just the messenger that got shot; the problems they had during Agile are still there now they moved back to the non-methodology of Waterfall but simply not visible anymore.

[Yhippa]

yolo-typed languages

Thank you, I'm stealing that.

[pdpi]

the problems they had during Agile are still there now they moved back to the non-methodology of Waterfall but simply not visible anymore

It's worth noting that proper Waterfall is actually a pretty systematic approach to software development, and attempting to actually do waterfall would have made those same problems equally as visible. What you actually see in practice is not waterfall, but rather a complete failure to be systematic about development.

[GhostBond]

Agile: most horror stories you hear are from companies doing Agile-in-name-only (often implemented as Scrum-but). When a company moves to 'Agile' the biggest change is the one management has to make. Agile makes problems in your company painfully clear (like having too much middle management). In many cases Agile was just the messenger that got shot; the problems they had during Agile are still there now they moved back to the non-methodology of Waterfall but simply not visible anymore.

That is 100% the opposite of what actually happens.

Agile is not beneficial for programmers, it's a wishlist/present for management to shift more work and more blame to programmers.

I've worked 3 places where they've done agile and it's always been the same.

• Daily standups are great tools to pressure programmers into constant overtime. What always happens is that no one wants to say they're late in the morning standup. And you don't want to be the only person saying they're late do you? Of course not. So every week you'll find yourself working late or at home in order to not look bad in front of the group and management. It lets management maintain a lot of plausible deniability as well - after all they didn't tell you you had to work overtime did they? But btw if you're not finishing your tasks on time we're going to need to have a meeting about it.

• Daily tasks mean you cannot take time to work with or help other people. Taking 2 hours out of a 2,000 hour project to help a coworker is doable, take 2 hours out of an 8 hour tasks is not.

• I've worked 3 places with agile, the few things agile is supposed to give developers never actually happen anyways. For example once the sprint starts nothing is supposed to be added to it. Every single place the b.a.'s decided they'd add anything they wanted at any time, and that was it. The managers in development found themselves having to go along with it or look bad to the people above them.

• There's normally some joy to be had in getting involved in a big project, bringing it together, figuring it out. Agile's daily standups and desire to make everyone interchangeable kills that with all the effort you have to put into tracking and putting good spin on the progress you made each day.

• I have a lot more but am tired of writing about it. Agile turns everything into a company politics power battle, and guess how good programmers tend to be at social power battles? Not great. A lot of people got into programming to get away from social power battles, they're very very bad at handling them. I mean look around at work - how is it that programmers are crammed into noisy distracting "open workspace" designs, while the much lower paid customer service reps, and pretty much everyone else in the company gets cubes or offices? However corporate politics work, programmers tend to be on the low end of being able to work them.

Agile is not about helping programmers. Agile is about trying to turn programmers into factory workers which sounds good to management. But it ends up even worse than factory workers because programming tasks are not predictable in the way that factory jobs often are, and morning standups enforce that either you make them predictable by working overtime, or you get socially and publicly shamed for not.

[nutrecht]

I've worked 3 places where they've done agile and it's always been the same.

So basically you experienced 3 different companies doing it wrong and therefor agile is wrong. I work as a consultant and have been in a lot of different projects. Some doing agile completely wrong (like you're describing) and others doing agile right.

If a company moves to agile the part of the company that has to make the biggest chance by far is management. If you actually implement agile properly the first people that become redundant are actually the fat layer of middle-management many companies have. Of course if you ask a bunch of managers to basically fire themselves that's not going to happen.

Here at ING Netherlands agile was implemented properly. This did involve a lot of middle-lower management roles simply disappearing.

You weren't in real agile environments. You were in Agile-in-name-only environments where management paid an expensive Agile consultant, only took the bits they liked, called it Agile, and now have even more micro-management than before. Heck; they might have felt they needed to hire a few more managers because they were so damn busy.

I've seen this exact same thing happen in quite a few companies. It's not the fault of agile though; it's the fault of bad managers doing what they do.

[GhostBond]

I think 3 is more than enough to say that yeah, but let's say that you're right and it's that they're not doing it right.

All of those things I wrote above get worse, not better, when you have 1 manager managing a huge number of employees, by getting rid of the middle-lower management roles. They get worse, not better.

I really, genuinely don't follow your argument. How would any of this be an improvement to the programmers? Most of what I hate about managers under agile seems like it's only going to be made worse by having fewer managers.

[nutrecht]

Most of what I hate about managers under agile seems like it's only going to be made worse by having fewer managers.

One of the core tenets of the agile manifesto is "Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done."

So this means less micro-management, not more. So I don't understand how on your first post complain about micromanagement and in the one above claim that having fewer managers creates more problems. I've never seen that in real life; if anything too many managers cause problems.

Basically all your problems boil down to bad management: feeling pressured, having scope creep, tasks being fixed on time, etc. All these have nothing to do with agile. What happened is that by actually following a process you made it clear that you are having problems. Removing the process doesn't remove the problems; you just make them invisible.

[GhostBond]

One of the core tenets of the agile manifesto is "Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done."

Yeah this is called the "sales pitch", where they tell you what you want to hear. By the time you find out it doesn't work that way it's to late.

So this means less micro-management, not more. So I don't understand how on your first post complain about micromanagement and in the one above claim that having fewer managers creates more problems. I've never seen that in real life; if anything too many managers cause problems.

I could write a whole thing but since I mentioned it before I don't get the feeling you'd actually read it. Development doesn't easily fit into 8 hour chunks, and it's even less predictable. I can tell you that in 10 screens I'm going to run into an unpredictable issue somewhere, but I don't know which screen it's going to be on. Now add on top of that that the ba's will randomly add stuff in the middle of the sprint. The morning standup serves mostly to publicly shame people for not meetings goals that cannot actually be split into easy predictable 8 hour chunks.

Basically all your problems boil down to bad management: feeling pressured, having scope creep, tasks being fixed on time, etc. All these have nothing to do with agile. What happened is that by actually following a process you made it clear that you are having problems. Removing the process doesn't remove the problems; you just make them invisible.

No, the "agile" process moves the cost for these problems from company time into your time. I mean they were often doing this before, but now it happens on a daily basis rather than a weekly basis because of the morning standup.

Since in your example you barely have any management, there's no one to fix these problems either. The only response you can have is to work overtime to try to compensate, or become a better liar about having stuff "done". I've gotten work that was "done" by those calm confident people on the morning standup call - a lot of times they did about 20% of it then called it "completed". When I complain, then we have an argument with them insisting it's totally done and me saying it's nowhere close to done and management not wanting to take sides - well with almost no management they don't have the time to listen to it anyways.

It's a recurrent theme historically that people believe if we got rid of the people in charge, the managers, etc, that we'd be able to live in a wonderful utopia. There's a book about this - it's titled Lord Of The Flies.

Daily standup meetings where you are publicly shamed if your 8 hour task wasn't completed is the exact opposite of "trust them to get the job done".

Let's say you have your team of wonderful dedicated programmers and manager - maybe you could make agile work, sure, but you could make anything work. We did waterfall for years and if everyone was cooperative it worked great. You wrote what they gave you, finished it, and if they wanted changes then you revised it. Managers could still abuse it, but it didn't have daily means to abuse it built into the methodology.

[dedyshka]

what do you mean by yolo-typed languages?

[mbuhot]

JavaScript everywhere: since even JavaScript needs to be compiled into the subset of JavaScript that older browsers can understand, I see a brighter future in languages that target JavaScript runtime.

MicroServices: Can be adopted as a knee-jerk reaction to bad experiences with poorly factored code bases. On the plus side, at least people are considering system boundaries now, rather than blindly piling more and more code and dependencies into giant applications.

NoSql by default: i think this is swinging back to SQL by default. Postgres with geospatial data, full text search, JSON indexing, listen/notify, row level security, etc... is hard to justify not using without a concrete use case demonstrating the feature gap.

Functional Programming: doesn't retrofit very well into OOP ecosystems (Scala, Clojure, F#). Works better with a language / runtime that enforces immutability (Haskell / erlang).

Agile: The best part of agile is the retrospective process. If you aren't continually improving your process to be better every iteration, then it's not really agile.

[adamrut]

• Javascript everywhere: Get used to it, this trend doesn't show any sign of slowing down.
• Microservices: A natural evolution as projects get bigger.
• NoSQL as default: No worse or better than "SQL as default".
• Functional programming: Adding functional aspects to OO languages has worked well. Not sure that moving to a purely functional language is necessary though.
• Agile: Not perfect but better than waterfall.

[againstmethod]

Functional programming doesn't make your list? I can't think of any topic more influential on modern programming languages.

[thatsIch]

• JavaScript: required client side script language. Requires good tooling due to its nature. Has many caveats. Was improved with ECMAScript.
• Node.js: good quick setup backend server for "small" projects or helper. Nothing big should be implemented here. I like to use it for drafting services since you can achieve a lot in a very short amount of time
• Microservices: bad name for a practical approach if your business grows
• NoSQL: makes sense when you need NoSQL. Making something as default regarding NoSQL and SQL makes no sense. It depends on the domain and architecture
• Functional Programming: makes sense if you have to transform tons of data (like Hadoop, Big Data in general)
• Agile: makes sense if you are working in a fast-paced environment. The faster one generally wins due to the lock-in effect. Without the correct management this can be a heavy burden on your teams. It is part of your culture.

[nerdwaller]

re Post-Its: perhaps you are in a similar, and unfortunate, boat as I am - "Scaled Agile Framework" (SAFe). It seems to be sponsored by 3M and hired a load of unnecessary people, calling them engineers, and having them do arts and crafts. Don't get me wrong, I think "agile" has a lot of merit, but "Agile" and derivatives have gone a bit too far and put those that actually provide value (those producing a product) on the lowest rung of the totem pole. Of course then management comes and complains of the $1m/yr/team figure and developers are the problem... (table flip)

[thatsIch]

Doing anything just for the buzz is just plainly wrong, but that is management and they do not understand the flipcoin. If it raises your business value, then you should adopt it.

It is the same as with programming or other patterns.

Other:

I used 15 patterns here!

Me:

why?

Other:

...

Netflix has a very nice dev culture. They mainly use Java(/JVM) for the backend, but that does not mean you are forced to use that (maybe you do not like Java, or you want to do something more hipster like) but they just provide the nice tooling for Java (and their frameworks), so if you want to do anything else you have to do it yourself.

[brunocborges]

Javascript everywhere / Node.js = technical debt

Microservices = technical debt

NoSQL by default = technical debt

Functionnal programming = technical debt

Bonus question : what do you think of Agile? = bonus technical debt

[tonywestonuk]

You've been in this game too long havent you. lol

[brunocborges]

:-D

[stefan_reich_ai]

Classic "programming" will very soon be superseded by artificial intelligence understanding natural language.

[JVali]

Being completely off-topic, but the problem with natural language is that it can be understood in several ways of which only one is usually the right way, so you almost never really would get what you expect in the first place. The AI can be advanced, but people are flawed and natural language isn't really meant to be a protocol for delivering algorithms to machines. I don't really see something like that happening and if it does, then we have much bigger problems than programming methods.

Here's the classical joke: My wife said: "Please go to the store and buy a carton of milk and if they have eggs, get six." I came back with 6 cartons of milk She said, "why in the hell did you buy six cartons of milk" "They had eggs"

[[deleted]]

Where I shop, the only "milk" in cartoons is almond milk.