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?
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?
90% rewriting builder scripts due to new .NET versions / new signing demands from CA authorities 10% coding :sigh:
-
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?
Let me agree with your sentiment by proposing the following analog: Even the software development itself is 90% thought and visualization and only 10% writing code.
The difficult we do right away... ...the impossible takes slightly longer.
-
Let me agree with your sentiment by proposing the following analog: Even the software development itself is 90% thought and visualization and only 10% writing code.
The difficult we do right away... ...the impossible takes slightly longer.
If one actually spent "85%" on scope, requirements, analysis and design, one would probably only need 15% to program it.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
-
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?
If one actually spent "85%" on scope, requirements, analysis and design, one would probably only need 15% to program it.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
-
If one actually spent "85%" on scope, requirements, analysis and design, one would probably only need 15% to program it.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
And then the 50%, at the back end, spent on testing. :-D If an organization is large enough or has standards to follow, it'll be blessed by not having to spend much time on requirements. I can see how that would became an absolute sink for time in a small organization developing bespoke software.
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing. -
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?
In the Coding part of development :- - 85 to 90 percent - code from Google/Bing search (includes ChatGPT) - 10 to 15 percent - original code
-
And then the 50%, at the back end, spent on testing. :-D If an organization is large enough or has standards to follow, it'll be blessed by not having to spend much time on requirements. I can see how that would became an absolute sink for time in a small organization developing bespoke software.
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing.Acceptance testing and user training is another matter. A "big" company has no "requirements"? That's like saying any car is good enough. Leather, no leather. Yoke, no yoke. The CEO has one set of requirements; everyone below him has to translate that into "their" requirements; and so on. To Excel or not to Excel. I've done small and big; they all have "requirements" that aren't on the shelf. The "problem" is a lack of visibility of methodologies. "Deliverables" is what makes a user go round. Not (lack of) progress reports; but design documents that work for "everyone". One has to keep the user "interested". Which means incremental "development" of things that can actually be put to use.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
-
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?
-
Acceptance testing and user training is another matter. A "big" company has no "requirements"? That's like saying any car is good enough. Leather, no leather. Yoke, no yoke. The CEO has one set of requirements; everyone below him has to translate that into "their" requirements; and so on. To Excel or not to Excel. I've done small and big; they all have "requirements" that aren't on the shelf. The "problem" is a lack of visibility of methodologies. "Deliverables" is what makes a user go round. Not (lack of) progress reports; but design documents that work for "everyone". One has to keep the user "interested". Which means incremental "development" of things that can actually be put to use.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
Quote:
A "big" company has no "requirements"?
Sorry, slopping wording. I meant that developers wouldn't have to spend much time on it because of a division of labor.
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing. -
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
