|
Cheers griff, family bit shocked as you would expect, eldest daughter took it hard, but fine now, they are all at the wife's family in UK for Christmas, so feeling the cold! Well cold compared to Cyprus at least.
|
|
|
|
|
Sorry to hear of your medical issues, hope all goes well for you.
PartsBin an Electronics Part Organizer - An updated version available!
JaxCoder.com
|
|
|
|
|
Hey Dave, glad to hear you're recovering!
Software Zen: delete this;
|
|
|
|
|
![Beer | [beer]](https://www.codeproject.com/script/Forums/Images/beer.gif) Here's to a quick and complete recovery!
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
"I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
|
|
|
|
|
take care remember the risk get out while u can
Caveat Emptor.
"Progress doesn't come from early risers – progress is made by lazy men looking for easier ways to do things." Lazarus Long
|
|
|
|
|
DaveAuld wrote: Big 5-0 tomorrow....
Congrats on the 50 years, buddy.
Jeremy Falcon
|
|
|
|
|
DaveAuld wrote: Take care everyone!
And you too! ![Rose | [Rose]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/rose.gif) And Happy Birthday! ![Jig | [Dance]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/jig.gif)
|
|
|
|
|
Recover soon
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Youngsters like yourself should hold on better 
Take care - do not rush back to work...
"Everybody is a genius. But if you judge a fish by its ability to climb a tree, it will live its whole life believing that it is stupid." ― Albert Einstein
|
|
|
|
|
I just added the book, Modern Software Engineering: Doing What Works to Build Better Software Faster[^] to my bookshelf & began reading it last night.
I am so amazed by this clear, clean, lucid explanation (& I'm always excited to find people/authors who think this way) that I had to share it.
These ideas of the foundation of what Software Engineering really is are what I've thought about building software for many years but have never been able to express them this way.
From the Introduction (my emphasis) Software development is a process of discovery and exploration; therefore, to succeed at it, software engineers need to become experts at learning.
When we organize our thinking this way and start to make progress on the basis of many small, informal experiments, we begin to limit our risk of jumping to inappropriate conclusions and end up doing a better job.
Software engineering is the application of an empirical, scientific approach to finding efficient, economic solutions to practical problems in software.
This means that we must manage the complexity of the systems that we create in ways that maintain our ability to learn new things and adapt to them.
So, we must become experts at learning and experts at managing complexity.
There are five techniques that form the roots of this focus on learning. Specifically, to become experts at learning, we need the following:
* Iteration
* Feedback
* Incrementalism
* Experimentation
* Empiricism
This is an evolutionary approach to the creation of complex systems. Complex systems don’t spring fully formed from our imaginations. They are the product of many small steps, where we try out our ideas and react to success and failure along the way. These are the tools that allow us to accomplish that exploration and discovery.
To become experts at managing complexity, we need the following:
* Modularity
* Cohesion
* Separation of Concerns
* Abstraction
* Loose Coupling
I really love this initial explanation.
We need two main strengths:
1. An expert understanding of Learning
2. Deep understanding of how to manage complexity
We'll never attain these entirely, but as we become better at both of those our ability to create elegant solutions grows by leaps & bounds.
Also, really like that the author includes the idea of incrementalism.
Complex systems can only be built from simple ones.
|
|
|
|
|
Echos of Yourdon.
Structured Analysis and Structured Design (SA/SD) - GeeksforGeeks
"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
|
|
|
|
|
That's an interesting article & Yourdon definitely built a foundation of Software Engineering.
Many of the ideas he expressed helped take those first steps to creating a way of communicating what we would build & how we were going to do it. 
I would definitely say he was attempting to
Build a system of learning
Attempting to manage complexity in those systems & the building of those systems.
|
|
|
|
|
Although I agree with what you've quoted, it really isn't new. And to be blunt, it's mostly platitudes. The challenge is how to actually achieve those characteristics in an actual system or even the process used to build it.
modified 19-Dec-22 11:02am.
|
|
|
|
|
Greg Utas wrote: it really isn't new.
I agree 100% with that. And, if you have many years of experience you probably have learned these along the way. I just think the author did a nice job of clearly setting a foundation of what SE is as a place to begin learning what you need to learn.
Greg Utas wrote: And to be blunt, it's mostly platitudes.
You are definitely correct there. Since anything does become a platitude if it is not carried out into implementation. However, i'm hoping that since the author has defined the two main ideas & then further broken them down into additional things that the book will provide more implementation that may be helpful.
Greg Utas wrote: challenge is how to actually achieve those characteristics in an actual system or even the process used to built it
Well said and again I agree 100%. I have a love/hate relationship with "books about Software Architecture/ Engineering" because so many of them end up just being a bunch of platitudes.
I was recently reading two other books* on architecture and if I had been reading physical copies I would have flung them across the room (or better yet, into the fireplace). So many of Architecture / Engineering books are just an author blathering on.
* Semantic Software Design[^]: A New Theory and Practical Guide for Modern Architects
Absolutely terrible - So much blather couldn't believe it.
Can't even remember the other one I was reading it was so terrible.
|
|
|
|
|
Thank you Greg, I was already gagging. Apologies to the original poster. The problem with software development is management. Period.
There are only some who can drive software development to simplicity. Do not manage complexity, remove it. Here's your sign - when you have to design to a trade show date but have no control over features, one side or the other is delusional. Or in denial. I'd argue that good software engineering, engineering in general or ANY constructive process succeeds when you stop doing what fails. I've worked in places where no one will change the CPU because we just need more power - instead, they will save $/board and spend 2 million in engineering dollars then slap the developers for their stupidity.
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 agree that management is often the problem, but hardly exclusively. It can be hard to get the domain model right, and kludgers are ever with us.
|
|
|
|
|
"Models are for sissies! Get to work!" 
|
|
|
|
|
I explained my attitude poorly. By management, there are the people who are not technical making product decisions and what not. There are others, senior developers, tech leads, whatever you want to call them, but someone technical *must* be in charge. That person has the "no that's not how we're going to do it" authority and actually uses it.
I have heard it said that managing sw developers is like herding cats. Someone has to be the dog, the captain, whatever metaphor you want  . I've worked on teams where everyone was really smart, some excessively so. The lead wanted us all to cooperate. What happened? kludge here, design change there, bugs later.
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.
|
|
|
|
|
You forgot to add these points about being a good programmer:
- You must think your preferred programming language is better than the others - because the others suck.
- You must learn to argue online about the tiniest of things - because you know better than those plebs.
- You must be quick to point out other's code flaws while never admitting your own.
- You must like Star Wars. Deal with it.
- Most importantly, a good programmer hates sunlight and house lights. Only n00bs turn the light on.
Jeremy Falcon
|
|
|
|
|
sarcassm?
that's where the senior engineer or product lead tells you to stfu or find another job. I'm sorry, engineering sometimes involves group cooperation, but there must be the evil overlord to keep the children from fighting.
I had an argument many years ago with a midrange developer who worked for me. He did not believe in source control / management. Really? I said. He said, yeah, complete waste of time. I blinked, and said, "you can't work for me, find another project." He said, "Really?" Every project needs leadership specifically technical leadership, not suggestive leadership. Group think is a total fail.
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: that's where the senior engineer or product lead tells you to stfu or find another job. I'm sorry, engineering sometimes involves group cooperation, but there must be the evil overlord to keep the children from fighting.
I'd never hire a senior that can't take a joke though. If you can't laugh, you're not that intelligent.
charlieg wrote: I had an argument many years ago with a midrange developer who worked for me. He did not believe in source control / management. Really? I said. He said, yeah, complete waste of time. I blinked, and said, "you can't work for me, find another project." He said, "Really?" Every project needs leadership specifically technical leadership, not suggestive leadership. Group think is a total fail.
Not sure how this relates to my joking, but sure ok. Keep in mind, it's your or your company's fault for hiring and/or calling a dude like that midrange. I wouldn't call that dude a junior.
Jeremy Falcon
|
|
|
|
|
Oh, well, I did ask . No we're good, and I meant my comment to indicate I picked up on it. What exactly results when you square sarcasm?
I just think it's hilarious that the biggest argument and passive rebellious behavior was about coding standards. Meanwhile, there was no standard for error checking. Even after project - 1 went through misery dealing with ftp errors, here we are again.
That's the point of the evil overlord, the passionate benevolent leader that doesn't have a problem about arguing and debating without HR getting involved.
Sorry, been in the trenches a long time
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.
|
|
|
|
|
About the quotes... I have always said: "The best I learned in college was to learn"
Side note:
I met the new division boss last week for the first time and had a chat with him.
During the conversation he said a similar approach to that.
A good boss needs two skills. Managing and leading.
Managing is to get an overview of what it is and make the best out of it.
Leading is to look at the future and see how can the status quo be improved and look for the proper steps to reach it, even when that implies to drop everything and to start over.
I found it an interesting point, too.
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
raddevus wrote: Software development is a process of discovery and exploration;
Errr...Software development is the process of delivering functionality on which businesses can make money.
The feel-good stuff only works as long as you are getting a nice big paycheck.
raddevus wrote: To become experts at managing complexity, we need the following:
Nice buzzwords but without the understanding of how to use those to facilitate long term actual cost reduction for the business they don't mean much. Without that understanding the misuse will lead to increased complexity which leads to more fragile software and higher maintenance costs.
But perhaps all of that is in a latter chapter.
|
|
|
|
|
Corrupt fully grown drug speed (10)
Life should not be a journey to the grave with the intention of arriving safely in a pretty and well-preserved body, but rather to skid in broadside in a cloud of smoke, thoroughly used up, totally worn out, and loudly proclaiming “Wow! What a Ride!" - Hunter S Thompson - RIP
modified 19-Dec-22 4:26am.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
