|
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 sh*t' 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?
modified 19-Jan-24 13:48pm.
|
|
|
|
|
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
|
|
|
|
|
Definitely an upvote for this reply 
On new projects, we're often like crows looking for food. Wait! Check this out, a new shiny object! Hours later, hmm, it doesn't do anything or do it better. 
|
|
|
|
|
90% rewriting builder scripts due to new .NET versions / new signing demands from CA authorities
10% coding
|
|
|
|
|
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
|
|
|
|
|
And then the 50%, at the back end, spent on testing. 
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.
|
|
|
|
|
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.
|
|
|
|
|
In the Coding part of development :-
- 85 to 90 percent - code from Google/Bing search (includes ChatGPT)
- 10 to 15 percent - original code
|
|
|
|
|
you are evil. Correct but evil
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.
|
|
|
|
|
We have enough problems just keeping the current system running in the face of all of the security squeezes.
Constant screw tightening.
|
|
|
|
|
The last project I worked on they tried that. But they soon abandoned the idea when they realised how much time was being wasted.
|
|
|
|
|
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
|
|
|
|
|
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#.
|
|
|
|
|
I'm proud to say it's probably about 99% coding in my company
Not for me of course, but I'm sales, marketing, HR, finance... 
|
|
|
|
|
"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 concepts are not difficult but due to technology, implementation can be. But our pattern is what was developed 30 years ago - the problem we're solving (it will never go away) is still the same.
I suspect that 90% (I made that up) of new software is solving the same problem in the problem space.
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.
|
|
|
|
|
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.
|
|
|
|
|
"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.
|
|
|
|
|
I would like to "publish" a guide to newly hired "customer service agent ".
Here is a start - in no particular order:
(do not fix it ) get a new one
it is a user's (customer's) fault
RTFM
"customer is always right " no longer applies
it is working fine here
|
|
|
|
|
Quote: it is working fine here
That's the one that gets me the most infuriated.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
... From both sides of that conversation.
"A little song, a little dance, a little seltzer down your pants"
Chuckles the clown
|
|
|
|
|
1. Clear your cache.
2. Clear your cookies.
3. Reboot.
I've almost told some of these types to get stuffed. What stops me is knowing it's rarely their fault, but that of people who want to put customers through an escalation sequence because 80% of the calls to the help desk are from idiots.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
