Developing software today ... 15% dev, 85% this and that
-
"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.