Developing software today ... 15% dev, 85% this and that
-
Keep in mind, I'm an older version, maybe I'm completely wrong ;) For me it looks these days 85% of the time we have for development goes into A.) 85% discussions/meetings about - Which pattern here and there - Dependency Injection here and there for loose coupling - Code review and refactoring ... and testing the 'whole shit' again - [Edit]Learning/recognize this and that syntactic suggar [/Edit] - .... B.) 15% Implementing the customer's request Don't get me wrong: All these Patterns and technics (DI, test driven dev, etc.) are pretty ok. But the religion around it takes too much of the resources :( Others who feel the same?
-
Keep in mind, I'm an older version, maybe I'm completely wrong ;) For me it looks these days 85% of the time we have for development goes into A.) 85% discussions/meetings about - Which pattern here and there - Dependency Injection here and there for loose coupling - Code review and refactoring ... and testing the 'whole shit' again - [Edit]Learning/recognize this and that syntactic suggar [/Edit] - .... B.) 15% Implementing the customer's request Don't get me wrong: All these Patterns and technics (DI, test driven dev, etc.) are pretty ok. But the religion around it takes too much of the resources :( Others who feel the same?
85% reading code and debugging to understand how the system works and how I should implement new changes so as to avoid breaking anything. 14% in meetings, admin, training, communications, reading documentation or articles related to what I am working on. 1% writing actual code.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
-
Keep in mind, I'm an older version, maybe I'm completely wrong ;) For me it looks these days 85% of the time we have for development goes into A.) 85% discussions/meetings about - Which pattern here and there - Dependency Injection here and there for loose coupling - Code review and refactoring ... and testing the 'whole shit' again - [Edit]Learning/recognize this and that syntactic suggar [/Edit] - .... B.) 15% Implementing the customer's request Don't get me wrong: All these Patterns and technics (DI, test driven dev, etc.) are pretty ok. But the religion around it takes too much of the resources :( Others who feel the same?
Sounds like greenfield project and junior team. Dependency injection is like air for me, we don't have to discuss anything it is just there and we just use it. Maybe if some junior joins we have to explain stuff but for any mid/senior we just don't talk. Same with patterns we don't build framework so we don't deal with god know what level of abstractions so we mostly build features. On the other hand there are discussions on interface as everyone feels like they should have an opinion if button should be more to the right or more to the left - but backend is solved problem for me at this point for a web application in .NET/C#.
-
IMO especially for new projects. 80% deciding what "technology of the day" to use 15% reverting back to trusted but boring technology. 5% coding.
CI/CD = Continuous Impediment/Continuous Despair
-
Keep in mind, I'm an older version, maybe I'm completely wrong ;) For me it looks these days 85% of the time we have for development goes into A.) 85% discussions/meetings about - Which pattern here and there - Dependency Injection here and there for loose coupling - Code review and refactoring ... and testing the 'whole shit' again - [Edit]Learning/recognize this and that syntactic suggar [/Edit] - .... B.) 15% Implementing the customer's request Don't get me wrong: All these Patterns and technics (DI, test driven dev, etc.) are pretty ok. But the religion around it takes too much of the resources :( Others who feel the same?
I'm proud to say it's probably about 99% coding in my company :D Not for me of course, but I'm sales, marketing, HR, finance... :sigh:
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
Keep in mind, I'm an older version, maybe I'm completely wrong ;) For me it looks these days 85% of the time we have for development goes into A.) 85% discussions/meetings about - Which pattern here and there - Dependency Injection here and there for loose coupling - Code review and refactoring ... and testing the 'whole shit' again - [Edit]Learning/recognize this and that syntactic suggar [/Edit] - .... B.) 15% Implementing the customer's request Don't get me wrong: All these Patterns and technics (DI, test driven dev, etc.) are pretty ok. But the religion around it takes too much of the resources :( Others who feel the same?
"Keep in mind, I'm an older version," At least in the far past problems that were solved by computers were significantly less complex. "85% discussions/meetings about" Can't speak to your current work situation but certainly I see value is making sure requirements (whatever form they take) are fully specified and understood. Then designs follow from that. The more complexity then the more important that becomes. Neither of those involve throwing code. I certainly would not want to use a bridge where they started throwing steel/concrete on day one of the contract being signed. "Code review and refactoring ... and testing the 'whole sh*t' again" Yes code review is important. Some examples. - A senior developer that could not seem to grasp how distributed applications worked with databases and was trying to use thread locks to control something that could only be handled by a database transaction. This happened multiple times. - Multiple different senior developers that wrote C# linq expressions to span/iterate through the entire hash table to do a key look up. - Senior developer that rewrote a simple switch/case factor pattern (incorrectly) to avoid a static code check which resulted in a production exception. Testing of course is important when code changes. "15% Implementing the customer's request" There is of course no guarantee that implementing processes will be done even close to correct. Not to mention other factors such as the following. - Personality problems. - Despite claims that every single company has above average programmers actual probability insures that there will in fact be below average programmers. - Management blame gaming which makes employees hyper-sensitive to touching anything. - Management blame gaming which makes employees hyper-sensitive to incomplete requirements. I worked with a Director recently that seemed to think that every problem could/would be solved by throwing more threads at the problem. Despite him have no actual technical experience with the product. So of course that meant threads got added.
-
Keep in mind, I'm an older version, maybe I'm completely wrong ;) For me it looks these days 85% of the time we have for development goes into A.) 85% discussions/meetings about - Which pattern here and there - Dependency Injection here and there for loose coupling - Code review and refactoring ... and testing the 'whole shit' again - [Edit]Learning/recognize this and that syntactic suggar [/Edit] - .... B.) 15% Implementing the customer's request Don't get me wrong: All these Patterns and technics (DI, test driven dev, etc.) are pretty ok. But the religion around it takes too much of the resources :( Others who feel the same?
"Patterns" have always been considered solutions looking for problems. Just because one uses them will not ensure that the coding will be any more efficient than quality coding by one who doesn't use them. The idea of the use of "patterns" became ever more encouraged with the advent of the Microsoft introduction of the ASP.NET MVC paradigm in 2010. It was BS then and it is still BS today...
Steve Naidamast Sr. Software Engineer Black Falcon Software, Inc. blackfalconsoftware@outlook.com
-
In the Coding part of development :- - 85 to 90 percent - code from Google/Bing search (includes ChatGPT) - 10 to 15 percent - original code
-
"Keep in mind, I'm an older version," At least in the far past problems that were solved by computers were significantly less complex. "85% discussions/meetings about" Can't speak to your current work situation but certainly I see value is making sure requirements (whatever form they take) are fully specified and understood. Then designs follow from that. The more complexity then the more important that becomes. Neither of those involve throwing code. I certainly would not want to use a bridge where they started throwing steel/concrete on day one of the contract being signed. "Code review and refactoring ... and testing the 'whole sh*t' again" Yes code review is important. Some examples. - A senior developer that could not seem to grasp how distributed applications worked with databases and was trying to use thread locks to control something that could only be handled by a database transaction. This happened multiple times. - Multiple different senior developers that wrote C# linq expressions to span/iterate through the entire hash table to do a key look up. - Senior developer that rewrote a simple switch/case factor pattern (incorrectly) to avoid a static code check which resulted in a production exception. Testing of course is important when code changes. "15% Implementing the customer's request" There is of course no guarantee that implementing processes will be done even close to correct. Not to mention other factors such as the following. - Personality problems. - Despite claims that every single company has above average programmers actual probability insures that there will in fact be below average programmers. - Management blame gaming which makes employees hyper-sensitive to touching anything. - Management blame gaming which makes employees hyper-sensitive to incomplete requirements. I worked with a Director recently that seemed to think that every problem could/would be solved by throwing more threads at the problem. Despite him have no actual technical experience with the product. So of course that meant threads got added.
"At least in the far past problems that were solved by computers were significantly less complex." Seriously? I'm looking at the Space Program, etc. You'd be amazed what was done in electronic warfare with Z8 processors. I'm interested in you elaborating a bit on this. I agree that we're doing some cutting edge stuff with gene analysis, etc., but I don't see the problem space getting more complicated. Honest question. "but certainly I see value in making sure requirements (whatever form they take) are fully specified and understood. Then designs follow from that." Curious if you ever read the Extreme Programming book - the original? I took a few nuggets from it as a development manager. The biggest one was that the customer really has no idea specifically what they want when it comes to a software system or application. They view it as solving a problem. I believe solving the problem is where the requirements should be. Defining requirements into the minutia will simply kill the project before making any progress. Let smart people make smart decisions. I'm seeing this now at the company a consult with. They are so focused on making sure the requirements are in place that if the developers were to wait for them, the project would never be delivered on their magic schedule. Mind you, marketing wants something by the end of the year, the requirements are not complete, and we're already writing code. :) The other thing I pulled from this book is unit tests. If a team can build a test suite that gives them test confidence in the code base, much freedom will occur. In one case in my 40+ years of engineering, mainly in embedded systems and what not, have I seen a good regression test. It took hardware to validate the product under test, but if we made changes to very complex areas, we threw it against the test system. As far as HMI stuff, I've never seen it done. "I certainly would not want to use a bridge where they started throwing steel/concrete on day one of the contract being signed." This is where patterns come into play. We build bridges all the time. We do the same thing in other areas. Everyone knows what a bridge is supposed to do. You already have your high level requirements :). What is the span of the bridge? How much load must it carry, etc. These are well understood. In software, just about every project is new and fancy. In my world, we're developing a product that performs the same basic function as the previous 3 products over the past 30 years. The concept
-
"Patterns" have always been considered solutions looking for problems. Just because one uses them will not ensure that the coding will be any more efficient than quality coding by one who doesn't use them. The idea of the use of "patterns" became ever more encouraged with the advent of the Microsoft introduction of the ASP.NET MVC paradigm in 2010. It was BS then and it is still BS today...
Steve Naidamast Sr. Software Engineer Black Falcon Software, Inc. blackfalconsoftware@outlook.com
sort of disagree. I think Patterns failed because it was applied at too low a level. It should have been left at the systems requirement level. that said, many system processes should be standardized. Logging, diagnostics, response to h/w failures, etc. This requires good management from empowered system engineers.
Charlie Gilley “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759 Has never been more appropriate.
-
"At least in the far past problems that were solved by computers were significantly less complex." Seriously? I'm looking at the Space Program, etc. You'd be amazed what was done in electronic warfare with Z8 processors. I'm interested in you elaborating a bit on this. I agree that we're doing some cutting edge stuff with gene analysis, etc., but I don't see the problem space getting more complicated. Honest question. "but certainly I see value in making sure requirements (whatever form they take) are fully specified and understood. Then designs follow from that." Curious if you ever read the Extreme Programming book - the original? I took a few nuggets from it as a development manager. The biggest one was that the customer really has no idea specifically what they want when it comes to a software system or application. They view it as solving a problem. I believe solving the problem is where the requirements should be. Defining requirements into the minutia will simply kill the project before making any progress. Let smart people make smart decisions. I'm seeing this now at the company a consult with. They are so focused on making sure the requirements are in place that if the developers were to wait for them, the project would never be delivered on their magic schedule. Mind you, marketing wants something by the end of the year, the requirements are not complete, and we're already writing code. :) The other thing I pulled from this book is unit tests. If a team can build a test suite that gives them test confidence in the code base, much freedom will occur. In one case in my 40+ years of engineering, mainly in embedded systems and what not, have I seen a good regression test. It took hardware to validate the product under test, but if we made changes to very complex areas, we threw it against the test system. As far as HMI stuff, I've never seen it done. "I certainly would not want to use a bridge where they started throwing steel/concrete on day one of the contract being signed." This is where patterns come into play. We build bridges all the time. We do the same thing in other areas. Everyone knows what a bridge is supposed to do. You already have your high level requirements :). What is the span of the bridge? How much load must it carry, etc. These are well understood. In software, just about every project is new and fancy. In my world, we're developing a product that performs the same basic function as the previous 3 products over the past 30 years. The concept
charlieg wrote:
but I don't see the problem space getting more complicated. Honest question.
And no one has been back to the moon since. Exceptions do not make the rule. In general now on average the scope of applications and services that need to be created are more complex than those that needed to be created long ago.
charlieg wrote:
Curious if you ever read the Extreme Programming book
yes. Along with probably hundreds of other books and decades of magazines. (lets see ... 20 years of one text book a month ... 20 x 12 = 240. Yep hundreds.)
charlieg wrote:
Let smart people make smart decisions
Programmers are not 'smart' people. They are average people. That is how normal distribution curves work. I have seen programmers do very stupid things. Process reduces the likelihood of that making its way to production. Doesn't eliminate it. Might not even be significant. But at least if it is not followed then one can point out the problem.
charlieg wrote:
40+ years of engineering
I also have that much experience. Most of the time working on complex systems, either with the explicit or implicit role of architect in multiple problem domain spaces. That includes start ups with less than 5 people to one company that had 2,000 developers.
charlieg wrote:
The other thing I pulled from this book is unit tests.
Just noting that I built a unit test framework before others existed. But also not sure how this follows on from your original OP.
charlieg wrote:
In software, just about every project is new and fancy.
I agree. But no idea how that relates to your original OP.
