I'm not in the business of selling code craft (believe it or not). I prefer to focus on helping those who're already sold on it make these technical practices work for them. But if you *want* to sell TDD, refactoring, CI, separation of concerns, CD etc, here's my tip: What appeals to business stakeholders is getting their hands on working software *sooner*. Sooner's a big deal. Not bugs. Not maintainability. Not "professionalism". How soon can we give them that change they asked for? All the roads of code craft lead to "shippable at any time"
Jason Gorman’s Post
More Relevant Posts
-
And if you do sell the boss on the benefit of short lead times for drama-free releases, then you typically have to have The Conversation™. Boss: That sounds great. Let's do that! Me: It's not that simple. Boss: Surely we just tick the "Continuous Delivery, please" box on our cloud hosting account don't we? That's what the sales guy told me. Me: It's really a skills thing. [ Produces skills road map for Continuous Delivery ] Boss: Our senior developers have these skills, though. It said so on their CVs. Me: Yeah. About that... 99% of developers don't. And that includes 90% of the ones who say they do. Boss: So we send them on a course? Me: That could be a good *start*. But realistically, after a good practical introduction to these skills, they'll need to get a lot of practice for them to be able to apply them day-to-day. Boss: How much practice, exactly? Me: You might want to sit down for this... What I've learned over the last 15 years, training and coaching thousands of developers and hundreds of teams in dozens of organisations, as well as driving initiatives in my contract days, is that it takes an average spend of 20-25% of your entire development budget to build and maintain this level of capability. Basically, one whole day a week for everyone working in development. Forever. And that, 99 times out of 100, is the end of The Conversation™. And why 99% of developers don't have those skills, and 99% of organisations don't have that capability. Plenty want to play like Beckham... But few are prepared to put in the time. So anyway, that's why I'm not in the business of selling code craft. I'm at the other end of that process, waiting for the 1% who've persuaded themselves.
I'm not in the business of selling code craft (believe it or not). I prefer to focus on helping those who're already sold on it make these technical practices work for them. But if you *want* to sell TDD, refactoring, CI, separation of concerns, CD etc, here's my tip: What appeals to business stakeholders is getting their hands on working software *sooner*. Sooner's a big deal. Not bugs. Not maintainability. Not "professionalism". How soon can we give them that change they asked for? All the roads of code craft lead to "shippable at any time"
To view or add a comment, sign in
-
Some things to consider when refactoring and writing code 🤔 Faster is not always better 🙀 Performance speed is really only one metric in a list of considerations and often times (depending on context) not even the most important one Good code is: ✅ Reliable ✅ Maintainable ✅ Readable ✅ Reusable ✅ Designed to handle likely edge cases ✅ And finally, performant, with these other considerations already addressed Anything you'd add to this list?
To view or add a comment, sign in
-
Is no-code enough for your business? Discover why leading industries still rely on custom code development for complex projects. Learn more about the limitations of no-code and why custom coding often provides the flexibility and scalability needed for success. https://ow.ly/yayn50TwQEs #nocode #customcode #customdevelopment
To view or add a comment, sign in
-
Refactoring is not something you can do at any time, any scale! Most people look at the “Refactoring” as a magic button. It is as easy as pushing it, any time he wants. Miss the point that refactoring needs planning from the start, when you decide to add technical debt for any reason. Planning for refactoring means getting prepared to change software at a minimum cost. The essential point, in my opinion, is making room for it by making boundaries and abstractions. so it is possible to change the codebase without the avalanche effect, which you force to refactor a large part of the codebase because of dependencies between them. Otherwise, although you call it a “Refactor”, it will cost as much as rewriting the code, maybe even more! #softwaredesign
To view or add a comment, sign in
-
Refactoring is a crucial step in maintaining code quality, improving performance, and ensuring scalability. 1. Identify the Problem Areas: Start by pinpointing inefficient, duplicated, or complex code segments. 2. Set Clear Goals: Define what you want to achieve with the refactor. 3.Start with Small Changes: Begin by refactoring small sections at a time, such as renaming variables, breaking down large functions... 4.Maintain Code Readability Prioritize code readability. should make the code easier to understand. 5. Optimize Performance: Look for opportunities to optimize performance. 6.Test Continuously: Continuously run and test each change to ensure that everything works. 7.Document Changes: Make sure to document significant changes.
To view or add a comment, sign in
-
[𝗖𝗹𝗲𝗮𝗻 𝗖𝗼𝗱𝗲] 𝗘𝗺𝗲𝗿𝗴𝗲𝗻𝗰𝗲 Rules for writing clean code are simple, and there are just a few of them. However, simple doesn't mean easy. What is difficult is repeatedly doing simple things, writing tests, and refactoring. Actually, you have to take time for this and deeply recognize that doing this kind of work doesn't mean stagnating but preparing for advancing better and faster. 𝗧𝗼𝗱𝗮𝘆'𝘀 𝗳𝗼𝗰𝘂𝘀: 𝗘𝗺𝗲𝗿𝗴𝗲𝗻𝗰𝗲. ----- You are not ready for deployment if your code is not clean. Clean code means maintainable. Maintainable means survival and growth.
To view or add a comment, sign in
-
Can be refactored != Should be refactored I should have added a disclaimer that some may get heated that not all code should be refactored. Let's chat about what might motivate us to refactor code: - Difficult to understand - Hard to make changes in - Very brittle when we do make changes - Little to no test coverage, and difficulty adding any - Cannot extend the code to perform any other functionality If code could benefit from refactoring, why might you opt to leave it as is? 👇Check out the comments for the link to the article!👇 ---- 📨 Sign up for my email newsletter! 🗣️ Share with your network! #refactoring
To view or add a comment, sign in
-
The Move Line Up/Down shortcut can save programmers a significant amount of time by simplifying the process of rearranging code. Overall, this shortcut helps you manage your code layout more fluidly, making it especially useful during code reviews, refactoring, or when adjusting code logic for clarity.
To view or add a comment, sign in
-
𝐈𝐧 𝐲𝐨𝐮𝐫 𝐂𝐨𝐝𝐞 , 𝐰𝐡𝐚𝐭 𝐢𝐬 𝐚 "𝐂𝐨𝐠𝐧𝐢𝐭𝐢𝐯𝐞 𝐂𝐨𝐦𝐩𝐥𝐞𝐱𝐢𝐭𝐲" ✔ it is a measure of how difficult a unit of code is to intuitively understand. ✔it tells you how difficult your code will be to read and understand. before you deploy your code , make sure to take care of this. Your code should be easy to read and understand and eventually would be easy to change. I take care of this - break your long function to small understandable, reusable & meaningful functions. Do you?
To view or add a comment, sign in
-
What matters: 1. Business Value. 2. Throughput. 3. Code Quality. In that order. Quality is 3rd only because it matters only if it’s missing. High quality code with no business value is pointless. High throughput with no business value is pointless. How many of you have seen an org focus on Throughput, while the product side and development side of the organization barely talk to each other?
To view or add a comment, sign in
Business/Software Coach, Mentor and Consultant; tdd.training
5moI'm curious about when people first remember articulating or hearing this idea. For me, it came around 2006 during discussions at a client site with Tim Ottinger, which he published as "Sooner, not Faster". He crystallized something that I'd been unartfully trying to say for a few years.