It's easy to tell a developer that resume-based development is a bad reason to choose a technology, but it is a very rational decision. I have seen far too many organizations that look for a certain level of tech stack as a filter to hire generalists. I remember in 2015-2018 seeing talented front end devs have trouble finding work because their resume didn't have SPA since their previous companies were using multi-page apps and jQuery. I remember seeing an organization do a complete replatform because they couldn't get people to work there - their technology was Tcl and the people inside (particularly those who started there as juniors) had trouble leaving. Resume based development can increase a developer's salary 10-30k in their next job. That's a very rational reason, unfortunately.
I believe it's a question of morality. Just like stealing from employer - it may be the rational thing to do, just isn't moral. Employer pays and trusts employee to perform their responsibilities on the level of their competences, so if an employee makes some technical decision in the name of the employer, knowing it's not good decision for company it is a kind of fraud
@@qj0n I agree, I think that there is an issue of honour, or morality, here. But I also think that there is, maybe, a deeper form of self-interest at play. Sure, you can 'cheat' and pick tech that makes it easier to get the next job that you want, but I am not convinced that that is a good way to get to work for the better employers. I think that the better employers are looking for something beyond a tick-list of technologies. When I was doing a lot of interviewing, I would see it as a down-mark when someone's CV we basically a list of tech. They would have to work harder to convince me that they weren't missing the whole point of SW dev, which is to solve problems, not to wield tech. A good dev can learn the tech in days to be useful and weeks to be good, so the tech is never my primary goal in recruiting, it is much more about how they work through problems to solve them. I know that my interview style is unusual, but I still think it is better 😉🤣 I think that you can gain some limited advantage by 'cheating' the system, but I think that you build much more advantage, and reputation, by having a laser focus on solving problems well, and doing that, to the best of your ability, in the interest of the companies that employ you. I am not 100% sure that I am right here, I can only speak from personal experience, but people liked working with me because, over time, they see that I am working in their interest, sometimes even if it doesn't align perfectly with mine. I have taken jobs using "less cool" technologies in the past, because that was the right choice for them, and there were other reasons for me wanting the job.
When things are too liberal, someone might start a project with their favorite toy, develop a whole system with it, and leave a trail of rubbish after they've left. I've seen that first hand and it's a huge problem. There is a lot of risk, for companies, associated with reckless technology adoption. On the other hand, it is also true that too much caution creates stagnation and crystallises people's skills. I've seen people that after 20+ years became totally unattractive to other employers. I guess it's worth having a process that does not prevent the adoption of new technologies but at the same time puts some governance on it. Finding the right balance is not easy.
We are here again aren't we? A lot of team leads picking technologies so they can change jobs if needed rather than picking the right tool for the job.
The worst I ever saw was that the international head office in Zurich mandated all subsidiaries to use SAP. That would cost us 5 years profits for a small standalone subsidiary, so we just created a small interface into another copy of SAP running at another local subsidiary and claimed we were on SAP, and that kept them off the trail for the four years I worked there.
A company that is forward-thinking should prioritize a minimalization of its tech stack. There are lots of frameworks out there, but once you start using them, you become dependent on them, and they can never replace the technology on which they are built.
All the videos on your channel makes very much sense (which is different from most of IT channels where content is just a somebody's opinion). Thanks for sharing your knowledge!
Choosing a tech is often difficult because people think they have to make the perfect decision upfront. Rather be agile and choose the easiest to implement/change tech. Then just change it later if need. This may not always be so simple, but I have found that if you have this mindset you normally build your software in a way that will allow change because you expect it.
Most of the worst technology choices I was faced with were related to relational databases: For example, using an RDBMS and ORM just because the infrastructure was already there and the team members were familiar with and not afraid of it, even though it was completely inadequate for the use case, leading to unnecessary complexity and doubling the overall cost. Conversely, we once inherited a one-person pet project for salvaging where a document store was used just because NoSQL was a popular buzzword at the time, even though the data looked exactly like a (poorly designed) relational model, thus leading to an unholy unmaintainable unreliable mess.
I like learning about new tech so I have a broader knowledge about possible solutions, but quite often the domain I'm in doesn't necessitate me learning about other languages/tech so I do it in my spare-time. Nor have I had the privilege to work with a company that fully allowed teams to pick a language, rather the language to use would be mandated by management/architects. I'm currently working for a client that is migrating away from COBOL-based services because some tech they use is EOL and there are no new developers that know COBOL. Yet for some reason, particular chunks of the new code-base are still being built in COBOL. Excellent video as always. Keep it coming 👍
Eagle use was highly risky because of Nazgul on flying beasts. Also, the characters do not think in such straight forward fashion, except for Boromir, and we know how that story ends.
Hey Continuous Delivery, I'm loving the videos as usual, but - minor gripe - what's with the stock video inserts? I don't remember them all being there and they certainly don't add to the content at all.
@@ainocorry3004 "Bothering" is probably too strong a word, but "distracting" is a good fit. The content of the inserts are vanilla, so IMO they are not additive to the central messages delivered by the speaker.
I think the point with the eagles links well to getting it all right up front. Let me explain, the difficult part was not actually getting the ring to the mountain of fire. It had been there before. The hard part was to throw it away once there. Which *spoiler alert* never happens. The habbits grew in capabilities on their journey and even made some progress rehabing Gollum. Out of that trajectory there were a few different arcs that could have led to success. From the direct route there was only ever one way it works out, a short all or nothing effort. A fundamental problem with that is no plan survives contact with the enemy (aka adversity). To me it sounds like waterfall and agile. The difference is facing that challenge with more capabilities and enough flex for chance events to be beneficial.
Gandalf didn't choose the Eagles because they were more powerful than him, and would have even more temptation to wield the One Ring. Hence, "one can't simply" fly over Mordor.
I have seen what happens IRL when a company follows an anything goes policy for tech stack. The reality is that teams shift, companies, pivot, people leave, and the more frameworks and technologies you have to deal with in production, the greater the maintenance burden. One former startup I worked at had three different relational DB vendors, two flavors of NoSQL, and code in seven different languages (including Delphi and Fortran), some running on Windows, other services on Linux. Monitoring was a nightmare in those days.
Resume driven development isn't even close to the worst I've seen. I've seen one where the DevOps guy didn't know how to program or automate anything, so all the tech choices had to cater to his limited skill set, which excluded any modern practice like CI/CD, containers or even basic deploy scripts. It's not like he lied in his resume either, someone higher up in that company actually thought this was a good idea. There are a lot of half-baked ideas you get when you chase the latest hotness, but I've never seen the latest hotness undo foundational things like automating your deployment.
No, no, no. That's completely wrong. Aragorn wanted to go through the Pass of Caradhras, while Gandalf wanted to go through Moria - and there was no nonsense about who's the leader and everyone mocking poor Gimli. The Fellowship was actually wary of Moria - Gimli included - and they tried Caradhras. In other words, they chose what seemed the reasonable option, but were forced by technical difficulties (no Saruman either, but snowstorms and being attacked by wolves) to go with another. Their second option wasn't good either; only Eru Illuvatar's intervention brings Gandalf back. And you had to bring up the eagles! As if Gandalf could command the eagles, and as if flying to Mordor was something they could do in secret and safety... as if Sauron wasn't looking for the Ring, as if there were no flying creatures (including the Nazguls' mounts) on Sauron's side, as if the Ring himself didn't have a will to corrupt its bearers and return to his master. Tolkien actually had a very good answer, see here: ua-cam.com/video/1-Uz0LMbWpI/v-deo.html Please, never use LoTR again in an argumentation - at least until you've read it.
There's still a good analogy to draw from here: no technology framework will transform a difficult task into a trivial one. There are no eagles to carry you all the way to Mordor.
The fellowship tried to be stealthy and inconspicuous. Flying to Mordor on eagles isn't exactly subtle. They would have been intercepted before they even got close. Besides, the eagles would probably have refused anyway.
Correct, but some problems are really good at hiding from sight before you start developing or even go live. That only means you should double or triple your effort to find these problems before choosing.
At a company I worked at 15 years ago, there was a guy who picked using Java to handle an SNMP messages. This was odd because the rest of the application was written in ADA. It became clear later that he only picked Java to put it on his resume. He got a job elsewhere and the company was stuck with insecure buggy code. This is why you should take your trade studies seriously!
Typical case of choosing a tech "just because". Earlier this year I pushed back an initiative to use Go for one of our tools. The developer wanted to learn Go but nobody else had knowledge in the language and looked like a risk.
“We” (Read not me) chose a tech stack because it looked great for 3 developers CVs and some of it was easy to code for. Then it was made so complicated as to be almost impossible to make sensible progress, release quickly or regularly. After all was said and done we were totally agile and released after 4 years of development work for the first time to rage reviews (Yes our customers raged at us and we got a terrible reputation from it). That’s all in the past though because muggins here was never allowed to state his opinion and this junk is now in production with me maintaining it while the developers have read about new frameworks and databases to use which no-one in the company knows about… Still who cares, at the end of this month I’m gone and now they have no choice but to hand this junk back to the devs because no-one else knows anything about it.
Some great reasoning in the video. I don't think Gandalf made the decision though. I believe he left it up to Frodo knowing his decision and others could be influenced by the ring. Same reason why the eagles never flew them to Mordor, the ring's influence. That and a flick of eagles flying in would certainly catch Sauron's attention. Regardless, great points on the pitfalls of decision-making on tech stacks. In my experience, it's often the loudest and most productive voice that leadership listens to, so if you have a reckless "rockstar" on the team leaving mounds of tech debt in their wake, good luck and godspeed.
Microservices give you the freedom to pick technologies but that's a freedom must use wisely. You can't blame microservices for using many different technologies - that's on you.
I watched the Linda Rising talk and found it worse than useless for Retrospectives. The underlying problem is the Prime Directive. It says we are going to ignore the elephants in the room. Instead of saying simply: we are here to improve how we work and blaming is not constructive so we won't tolerate it. The Prime Directive is reminiscent of Dale Carnegie's HTWFAIP which is read by people who think they are sincere and want to be sure they appear so, and helpful at every opportunity. In my experience their behavior is always self-conscious and appears forced. I can't have a productive Retrospective with such people. Some even turn out to be "fair weather friends", circling the wagons and abandoning you when the chips are down.
IMHO, the Prime Directive is a way to get into the mindset that people did the best they could, and if they failed, we might be able to help them in the future. If we actually take the time to listen and think about if the failure is caused by; lack of information, lack of time, lack of energy, lack of skill, or something else. I agree that it can be interpreted as "never talk about bad stuff", in which case the retrospective is indeed a waste of time. To me, a retrospective is a chance for a team to reflect, share, understand and learn together. And if we are blinded by trying to find a scapegoat and punish them, we are not constructively trying to understand and learn how to improve as a team. I know that there are psychopathic narcissists out there that want to ruin things. But the majority wants to do a good job and if they don't, it is more constructive to meet that conversation with an open mind that tries to find explanations, instead of faults in people. Are you facilitating retrospectives yourself? How do you make sure people share the things that did not go as planned?
Someone at my last company moved a bunch of APIs to GraphQL without really getting buy-in from the team, and it ended up slowing people down and not doing what was needed from that API -- let's just say schema design was definitely not his forte. He admitted later that he wanted to be able to say he architected a GraphQL API. He left the company shortly after that, presumably having got a better job for putting that line on his resume, and that code was eventually ripped out. It was such a waste for everyone else.
Enthusiasm for new toys is not necessarily a bad basis for choosing a technology. Life is too short to deny yourself shiny things. Maybe it’s overkill, but maybe it’s also keeping the dev team engaged.
Indeed, you should continue to learn, and try new things. But it is good to be aware of what the reason is. It might make it easier to change if it does not work well for the job?
I think it depends on why you are making the choice. New and shiny isn't always bad, if you think the new shiny thing will genuinely help to solve the problem better, but if you ONLY chose the new shiny thing for personal reasons, either not knowing, or worse, not caring whether this will help to achieve the goal of the work, then I think that this is amateurish to be honest. You need to think critically and sceptically when adopting new things. Try them out and then decide, not just buy into the hype of the new and shiny. I am sometimes an early adopter for tech, but I have tried to find the flaws in it for myself, before jumping into it though. First, can it do what you need, and only then decide if it is more fun. For example, for a very long time my evaluation of any new tech starts with "Can I version control it?", "Can I automate its deployment?" and "Does it allow for TDD?". If the answer to any of these is "No" I am not interested and will have to be dragged kicking and screaming into using it. 😉
In a professional context, "enthusiasm for new toys" is a personal feeling, whilst "choosing a technology" is a collective action. The problem is how you bridge the gap between those two, i.e. how you transform your enthusiasm for new toys into a projection of tangible benefits for the organization you work for. There should be a dialogue of some type and a consent like that Aino was mentioning should mature. You might not know if there will be benefits, therefore you ask to experiment, but experiments must be controlled and with well-defined expectations, otherwise the risk of going off tangents is high. I've seen all of that in my career. Deciding on new technologies carries a lot of risk for organizations. A developer might leave after a couple of years, but systems written with a specific stack might survive them much longer.
That is fine when the tool choice does not matter so much, but if everything hinges on the success of the project and its tool choice - then gambling for fun may have harsh consequences.
One thing I've learned about choosing technologies, never ask your cat for advice, (s)he'll anyways suggest Maui. Oh, and 9/10 times start with a simple modular monolith, most of the times microservices are overkill.
I think overuse of blockchain, AI or whatever else is usually a problem on business level, not technology. It's not developers who pushed blockchain into products. Management knows that particular buzzword can attract investors so it was a business decision to push those features there
I think that both cases apply. Sometimes it is for commercial advantage - "buzz-word compliance" and sometimes it is for CV/Resume packing for a particular Dev or team.
Sure, pearl is not be the best choice for an e commerce project, which is why we are now in the fourth year of having a second legacy systems in Java to maintain. Don't ask me why java was chosen though. or by whom. :D
Regardless of what you choose, it is highly likely that the thing will be here today and gone tomorrow ... even stuff put out to the world by google. How many of us burnt their fingers on GWT and other frameworks or technologies ? So a lot is just a gamble. You may as well just draw straws ?
I've seen this version of terrible decision making TWICE in 2 different orgs: "Great presentation!" was the only known reason for selecting a possible vendor. Both places no technical rep had been part of the assessment. Both places the cost and poor decision making (rooted in sunk cost fallacy) was massive... I have yet to see any team do as impactful and expensive poor decision making.
This is a very intersting question. In my team we have such a decision to make. And old application will be re-written but the decision of what language to chose is not yet done. For some time Kotlin was chosen, but me and another colleague have no experience with it than some tinkering, but a lot of Java knowledge. Java does not (yet) bring everything we need, such as coroutines, but there are frameworks available and with Java 21 this should also be done thanks to virtual threads. Another younger colleague, who has not much experience at all in programming, mainly his work for his degree and some private tinkering wants to use Kotlin instead. The usual null is bad and boilerplate code arguments. Kotlin has some advantages here, but with a team that knows how to do things in Java but not in Kotlin "the Kotlin-way" does not seem to be a good idea.
My honest answer is that I think that language choice won't make a significant difference, the quality of the design choices that you make will be of MUCH bigger significance. There is NOTHING that you can do with co-routines, that you can't achieve by other means, for example. I know that this is an unpopular opinion, but I think that the degree to which language choice really matters, at least for most modern, well-supported, reasonably popular, languages go, is raw performance at the limits of performance, integration with unusual technologies (check support if the tech matters to the project) and ability to find devs with enough knowledge to use it. The last of these doesn't matter very much, certainly not as far as the difference between Java, Kotlin, C#, or even Python go. If you know one of these, you can learn enough to write code in the other in a couple of weeks, and if you are good at one of these, you can be good at another in a month! The difference is ALL ABOUT DESIGN, what you make, not the tools that you use to make it. Just my 2c! 😉
@@ContinuousDelivery Agree, due to (the popular use of the term) Turing-equivalence, people can and will simulate any language construct in any other language. Sometimes with a less elegant result, but it can be done :-) Despite this, language choice is often heavily debated, but in the end, if you want the job done, you are way faster in a language you are fluent in.
It's easy to tell a developer that resume-based development is a bad reason to choose a technology, but it is a very rational decision. I have seen far too many organizations that look for a certain level of tech stack as a filter to hire generalists. I remember in 2015-2018 seeing talented front end devs have trouble finding work because their resume didn't have SPA since their previous companies were using multi-page apps and jQuery.
I remember seeing an organization do a complete replatform because they couldn't get people to work there - their technology was Tcl and the people inside (particularly those who started there as juniors) had trouble leaving.
Resume based development can increase a developer's salary 10-30k in their next job. That's a very rational reason, unfortunately.
I agree, it is a good reason from the point of view of the specific developer!
I believe it's a question of morality. Just like stealing from employer - it may be the rational thing to do, just isn't moral. Employer pays and trusts employee to perform their responsibilities on the level of their competences, so if an employee makes some technical decision in the name of the employer, knowing it's not good decision for company it is a kind of fraud
@@qj0n I agree, I think that there is an issue of honour, or morality, here. But I also think that there is, maybe, a deeper form of self-interest at play.
Sure, you can 'cheat' and pick tech that makes it easier to get the next job that you want, but I am not convinced that that is a good way to get to work for the better employers. I think that the better employers are looking for something beyond a tick-list of technologies. When I was doing a lot of interviewing, I would see it as a down-mark when someone's CV we basically a list of tech. They would have to work harder to convince me that they weren't missing the whole point of SW dev, which is to solve problems, not to wield tech.
A good dev can learn the tech in days to be useful and weeks to be good, so the tech is never my primary goal in recruiting, it is much more about how they work through problems to solve them. I know that my interview style is unusual, but I still think it is better 😉🤣
I think that you can gain some limited advantage by 'cheating' the system, but I think that you build much more advantage, and reputation, by having a laser focus on solving problems well, and doing that, to the best of your ability, in the interest of the companies that employ you.
I am not 100% sure that I am right here, I can only speak from personal experience, but people liked working with me because, over time, they see that I am working in their interest, sometimes even if it doesn't align perfectly with mine.
I have taken jobs using "less cool" technologies in the past, because that was the right choice for them, and there were other reasons for me wanting the job.
When things are too liberal, someone might start a project with their favorite toy, develop a whole system with it, and leave a trail of rubbish after they've left. I've seen that first hand and it's a huge problem. There is a lot of risk, for companies, associated with reckless technology adoption. On the other hand, it is also true that too much caution creates stagnation and crystallises people's skills. I've seen people that after 20+ years became totally unattractive to other employers. I guess it's worth having a process that does not prevent the adoption of new technologies but at the same time puts some governance on it. Finding the right balance is not easy.
We are here again aren't we? A lot of team leads picking technologies so they can change jobs if needed rather than picking the right tool for the job.
Because a popular UA-camr advocates it... I've really come around to appreciating Dave's focus on design over tech.
Delphi is the forgotten "Eagles" solution to many projects. It has been the technology behind many, many successful projects over the last 25+ years.
I have to make my choice based on the employer I'm locked into.
The best technology choice is often not the right choice, once you take into account the business factors specific to your situation.
I think that is often the case. Constraints can make you very creative! (to look at the bright side)
The worst I ever saw was that the international head office in Zurich mandated all subsidiaries to use SAP. That would cost us 5 years profits for a small standalone subsidiary, so we just created a small interface into another copy of SAP running at another local subsidiary and claimed we were on SAP, and that kept them off the trail for the four years I worked there.
Smart! I think...
A company that is forward-thinking should prioritize a minimalization of its tech stack. There are lots of frameworks out there, but once you start using them, you become dependent on them, and they can never replace the technology on which they are built.
All the videos on your channel makes very much sense (which is different from most of IT channels where content is just a somebody's opinion). Thanks for sharing your knowledge!
Thank you :-)
if possible please share the Linda talk video.
Choosing a tech is often difficult because people think they have to make the perfect decision upfront. Rather be agile and choose the easiest to implement/change tech. Then just change it later if need. This may not always be so simple, but I have found that if you have this mindset you normally build your software in a way that will allow change because you expect it.
Most of the worst technology choices I was faced with were related to relational databases: For example, using an RDBMS and ORM just because the infrastructure was already there and the team members were familiar with and not afraid of it, even though it was completely inadequate for the use case, leading to unnecessary complexity and doubling the overall cost. Conversely, we once inherited a one-person pet project for salvaging where a document store was used just because NoSQL was a popular buzzword at the time, even though the data looked exactly like a (poorly designed) relational model, thus leading to an unholy unmaintainable unreliable mess.
"Be nice to yourself!" I love this video and everything it stands for.
Thank you!
I like learning about new tech so I have a broader knowledge about possible solutions, but quite often the domain I'm in doesn't necessitate me learning about other languages/tech so I do it in my spare-time. Nor have I had the privilege to work with a company that fully allowed teams to pick a language, rather the language to use would be mandated by management/architects.
I'm currently working for a client that is migrating away from COBOL-based services because some tech they use is EOL and there are no new developers that know COBOL.
Yet for some reason, particular chunks of the new code-base are still being built in COBOL.
Excellent video as always. Keep it coming 👍
Thank you!
Another worst way to choice a technology is the "cargo-culture" approach, e.g. let's use X because [Google, Amazon, Netflix, etc...] use it 😢
Yes, and that happens all the time!
Eagle use was highly risky because of Nazgul on flying beasts. Also, the characters do not think in such straight forward fashion, except for Boromir, and we know how that story ends.
Also, the nature of Sauron was he foresaw all obvious risks, only the most unlikely approaches had a chance of success.
Ah, makes sense. @@michaelnurse9089
This was a brilliant video. Extremely funny and educational. Great analogy with the Lord of the rings scene reference too
Thank you:)
Hey Continuous Delivery, I'm loving the videos as usual, but - minor gripe - what's with the stock video inserts? I don't remember them all being there and they certainly don't add to the content at all.
This is a new thing we are trying out. Are they bothering you?
@@ainocorry3004 "Bothering" is probably too strong a word, but "distracting" is a good fit. The content of the inserts are vanilla, so IMO they are not additive to the central messages delivered by the speaker.
Ah, I see. Thank you! @@TheVampWillow
I think the point with the eagles links well to getting it all right up front. Let me explain, the difficult part was not actually getting the ring to the mountain of fire. It had been there before. The hard part was to throw it away once there. Which *spoiler alert* never happens. The habbits grew in capabilities on their journey and even made some progress rehabing Gollum. Out of that trajectory there were a few different arcs that could have led to success. From the direct route there was only ever one way it works out, a short all or nothing effort. A fundamental problem with that is no plan survives contact with the enemy (aka adversity). To me it sounds like waterfall and agile. The difference is facing that challenge with more capabilities and enough flex for chance events to be beneficial.
Gandalf didn't choose the Eagles because they were more powerful than him, and would have even more temptation to wield the One Ring. Hence, "one can't simply" fly over Mordor.
Hmm..
I have seen what happens IRL when a company follows an anything goes policy for tech stack. The reality is that teams shift, companies, pivot, people leave, and the more frameworks and technologies you have to deal with in production, the greater the maintenance burden. One former startup I worked at had three different relational DB vendors, two flavors of NoSQL, and code in seven different languages (including Delphi and Fortran), some running on Windows, other services on Linux. Monitoring was a nightmare in those days.
Resume driven development isn't even close to the worst I've seen. I've seen one where the DevOps guy didn't know how to program or automate anything, so all the tech choices had to cater to his limited skill set, which excluded any modern practice like CI/CD, containers or even basic deploy scripts. It's not like he lied in his resume either, someone higher up in that company actually thought this was a good idea.
There are a lot of half-baked ideas you get when you chase the latest hotness, but I've never seen the latest hotness undo foundational things like automating your deployment.
It sounds like he wasn't a "devops" even if we assume that devops is a role
No, no, no. That's completely wrong. Aragorn wanted to go through the Pass of Caradhras, while Gandalf wanted to go through Moria - and there was no nonsense about who's the leader and everyone mocking poor Gimli. The Fellowship was actually wary of Moria - Gimli included - and they tried Caradhras.
In other words, they chose what seemed the reasonable option, but were forced by technical difficulties (no Saruman either, but snowstorms and being attacked by wolves) to go with another. Their second option wasn't good either; only Eru Illuvatar's intervention brings Gandalf back.
And you had to bring up the eagles! As if Gandalf could command the eagles, and as if flying to Mordor was something they could do in secret and safety... as if Sauron wasn't looking for the Ring, as if there were no flying creatures (including the Nazguls' mounts) on Sauron's side, as if the Ring himself didn't have a will to corrupt its bearers and return to his master.
Tolkien actually had a very good answer, see here: ua-cam.com/video/1-Uz0LMbWpI/v-deo.html
Please, never use LoTR again in an argumentation - at least until you've read it.
There's still a good analogy to draw from here: no technology framework will transform a difficult task into a trivial one. There are no eagles to carry you all the way to Mordor.
I promise!
@@ainocorry3004 But please don't mind too much the strictness regarding Tolkien's works. I really appreciate what you and Dave are doing.
Gandalf's decision about the Eagles is due to the Eagle's nature. The Silmarilion explains it.
Conclusion: Read the documentation of your framework :D
Ah... Yes.. I deserved that :-)
...and correct mistakes after you find them, e.g. by writing an addendum to the story 🤣🤣
Brave comment, Dave :-)@@ContinuousDelivery
The fellowship tried to be stealthy and inconspicuous. Flying to Mordor on eagles isn't exactly subtle. They would have been intercepted before they even got close.
Besides, the eagles would probably have refused anyway.
The biggest and most common mistake is choosing technology long before understanding problems.
Correct, but some problems are really good at hiding from sight before you start developing or even go live. That only means you should double or triple your effort to find these problems before choosing.
@@michaelnurse9089 It is often very difficult due to management short sights, poor planning or budget constraints.
At a company I worked at 15 years ago, there was a guy who picked using Java to handle an SNMP messages. This was odd because the rest of the application was written in ADA.
It became clear later that he only picked Java to put it on his resume. He got a job elsewhere and the company was stuck with insecure buggy code. This is why you should take your trade studies seriously!
At least he was happy....
Typical case of choosing a tech "just because". Earlier this year I pushed back an initiative to use Go for one of our tools. The developer wanted to learn Go but nobody else had knowledge in the language and looked like a risk.
“We” (Read not me) chose a tech stack because it looked great for 3 developers CVs and some of it was easy to code for. Then it was made so complicated as to be almost impossible to make sensible progress, release quickly or regularly. After all was said and done we were totally agile and released after 4 years of development work for the first time to rage reviews (Yes our customers raged at us and we got a terrible reputation from it). That’s all in the past though because muggins here was never allowed to state his opinion and this junk is now in production with me maintaining it while the developers have read about new frameworks and databases to use which no-one in the company knows about… Still who cares, at the end of this month I’m gone and now they have no choice but to hand this junk back to the devs because no-one else knows anything about it.
Beautifully written video
Thank you!
Some great reasoning in the video. I don't think Gandalf made the decision though. I believe he left it up to Frodo knowing his decision and others could be influenced by the ring. Same reason why the eagles never flew them to Mordor, the ring's influence. That and a flick of eagles flying in would certainly catch Sauron's attention.
Regardless, great points on the pitfalls of decision-making on tech stacks.
In my experience, it's often the loudest and most productive voice that leadership listens to, so if you have a reckless "rockstar" on the team leaving mounds of tech debt in their wake, good luck and godspeed.
love this vido. I love your book!
Thank you!
Why not just use the eagles to fly to mordor? Here is the answer provided by Tolkien: ua-cam.com/video/1-Uz0LMbWpI/v-deo.html
I will listen and learn!
Oh, you put the link already... yeah, excellent answer.
Microservices give you the freedom to pick technologies but that's a freedom must use wisely. You can't blame microservices for using many different technologies - that's on you.
Agree. But with possibility comes a responsibility that you might not be used to.
I watched the Linda Rising talk and found it worse than useless for Retrospectives. The underlying problem is the Prime Directive. It says we are going to ignore the elephants in the room. Instead of saying simply: we are here to improve how we work and blaming is not constructive so we won't tolerate it.
The Prime Directive is reminiscent of Dale Carnegie's HTWFAIP which is read by people who think they are sincere and want to be sure they appear so, and helpful at every opportunity. In my experience their behavior is always self-conscious and appears forced. I can't have a productive Retrospective with such people. Some even turn out to be "fair weather friends", circling the wagons and abandoning you when the chips are down.
IMHO, the Prime Directive is a way to get into the mindset that people did the best they could, and if they failed, we might be able to help them in the future. If we actually take the time to listen and think about if the failure is caused by; lack of information, lack of time, lack of energy, lack of skill, or something else. I agree that it can be interpreted as "never talk about bad stuff", in which case the retrospective is indeed a waste of time.
To me, a retrospective is a chance for a team to reflect, share, understand and learn together. And if we are blinded by trying to find a scapegoat and punish them, we are not constructively trying to understand and learn how to improve as a team. I know that there are psychopathic narcissists out there that want to ruin things. But the majority wants to do a good job and if they don't, it is more constructive to meet that conversation with an open mind that tries to find explanations, instead of faults in people.
Are you facilitating retrospectives yourself? How do you make sure people share the things that did not go as planned?
Someone at my last company moved a bunch of APIs to GraphQL without really getting buy-in from the team, and it ended up slowing people down and not doing what was needed from that API -- let's just say schema design was definitely not his forte. He admitted later that he wanted to be able to say he architected a GraphQL API. He left the company shortly after that, presumably having got a better job for putting that line on his resume, and that code was eventually ripped out. It was such a waste for everyone else.
In US politics there is Democracy, but no consent = ever escalating feelings of ill will.
Yup, that is very sad indeed..
Enthusiasm for new toys is not necessarily a bad basis for choosing a technology. Life is too short to deny yourself shiny things. Maybe it’s overkill, but maybe it’s also keeping the dev team engaged.
Indeed, you should continue to learn, and try new things. But it is good to be aware of what the reason is. It might make it easier to change if it does not work well for the job?
I think it depends on why you are making the choice. New and shiny isn't always bad, if you think the new shiny thing will genuinely help to solve the problem better, but if you ONLY chose the new shiny thing for personal reasons, either not knowing, or worse, not caring whether this will help to achieve the goal of the work, then I think that this is amateurish to be honest. You need to think critically and sceptically when adopting new things. Try them out and then decide, not just buy into the hype of the new and shiny. I am sometimes an early adopter for tech, but I have tried to find the flaws in it for myself, before jumping into it though.
First, can it do what you need, and only then decide if it is more fun. For example, for a very long time my evaluation of any new tech starts with "Can I version control it?", "Can I automate its deployment?" and "Does it allow for TDD?". If the answer to any of these is "No" I am not interested and will have to be dragged kicking and screaming into using it. 😉
In a professional context, "enthusiasm for new toys" is a personal feeling, whilst "choosing a technology" is a collective action. The problem is how you bridge the gap between those two, i.e. how you transform your enthusiasm for new toys into a projection of tangible benefits for the organization you work for. There should be a dialogue of some type and a consent like that Aino was mentioning should mature. You might not know if there will be benefits, therefore you ask to experiment, but experiments must be controlled and with well-defined expectations, otherwise the risk of going off tangents is high. I've seen all of that in my career. Deciding on new technologies carries a lot of risk for organizations. A developer might leave after a couple of years, but systems written with a specific stack might survive them much longer.
That is fine when the tool choice does not matter so much, but if everything hinges on the success of the project and its tool choice - then gambling for fun may have harsh consequences.
I agree! But I also write frontend Rust...so...yea...
Thank you!
You are most welcome!
One thing I've learned about choosing technologies, never ask your cat for advice, (s)he'll anyways suggest Maui.
Oh, and 9/10 times start with a simple modular monolith, most of the times microservices are overkill.
Agree with both the cat and the monolith!
Even if microservices aren't an overkill, they can be introduced later and you better have a monolith in the beginning
Indeed @@qj0n
Nothing concrete just a bunch of words. The kind of stuff some managers use to justify their existence
I think overuse of blockchain, AI or whatever else is usually a problem on business level, not technology. It's not developers who pushed blockchain into products.
Management knows that particular buzzword can attract investors so it was a business decision to push those features there
I think that both cases apply. Sometimes it is for commercial advantage - "buzz-word compliance" and sometimes it is for CV/Resume packing for a particular Dev or team.
This. Many times is the business guys that chose technologies because the buzzwords or a % of the sale
Sure, pearl is not be the best choice for an e commerce project, which is why we are now in the fourth year of having a second legacy systems in Java to maintain. Don't ask me why java was chosen though. or by whom. :D
Awesome! Great points.
Thank you!
Great talk!
Thank you!
Excellent!
Thank you!
Regardless of what you choose, it is highly likely that the thing will be here today and gone tomorrow ... even stuff put out to the world by google. How many of us burnt their fingers on GWT and other frameworks or technologies ? So a lot is just a gamble. You may as well just draw straws ?
There is no way to make the "right" decision. So perhaps drawing straws would be better on average than spending time discussing...?
I've seen this version of terrible decision making TWICE in 2 different orgs: "Great presentation!" was the only known reason for selecting a possible vendor.
Both places no technical rep had been part of the assessment.
Both places the cost and poor decision making (rooted in sunk cost fallacy) was massive...
I have yet to see any team do as impactful and expensive poor decision making.
This is a very intersting question. In my team we have such a decision to make. And old application will be re-written but the decision of what language to chose is not yet done. For some time Kotlin was chosen, but me and another colleague have no experience with it than some tinkering, but a lot of Java knowledge. Java does not (yet) bring everything we need, such as coroutines, but there are frameworks available and with Java 21 this should also be done thanks to virtual threads. Another younger colleague, who has not much experience at all in programming, mainly his work for his degree and some private tinkering wants to use Kotlin instead. The usual null is bad and boilerplate code arguments. Kotlin has some advantages here, but with a team that knows how to do things in Java but not in Kotlin "the Kotlin-way" does not seem to be a good idea.
My honest answer is that I think that language choice won't make a significant difference, the quality of the design choices that you make will be of MUCH bigger significance.
There is NOTHING that you can do with co-routines, that you can't achieve by other means, for example.
I know that this is an unpopular opinion, but I think that the degree to which language choice really matters, at least for most modern, well-supported, reasonably popular, languages go, is raw performance at the limits of performance, integration with unusual technologies (check support if the tech matters to the project) and ability to find devs with enough knowledge to use it.
The last of these doesn't matter very much, certainly not as far as the difference between Java, Kotlin, C#, or even Python go. If you know one of these, you can learn enough to write code in the other in a couple of weeks, and if you are good at one of these, you can be good at another in a month!
The difference is ALL ABOUT DESIGN, what you make, not the tools that you use to make it.
Just my 2c! 😉
@@ContinuousDelivery
@@ContinuousDelivery Agree, due to (the popular use of the term) Turing-equivalence, people can and will simulate any language construct in any other language. Sometimes with a less elegant result, but it can be done :-) Despite this, language choice is often heavily debated, but in the end, if you want the job done, you are way faster in a language you are fluent in.
Only an Agile Coach knows how to be gentle with programmers' fragile egos while subtly revealing best practices.
😄
@@ainocorry3004 best practice to teach best practice to programers is to include lotr lore into your explanation.
this was interesting
Thank you!
It is quite clear you misunderstood the Lord of the Rings. Excellent talk otherwise, thanks!
Most likely :-) And thank you!