Software Engineering: Do You Concur?

raddevus

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: * Modularit

Lost User

Echos of Yourdon. [Structured Analysis and Structured Design (SA/SD) - GeeksforGeeks](https://www.geeksforgeeks.org/structured-analysis-and-structured-design-sa-sd/)

"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

raddevus

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. :thumbsup: 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. :thumbsup::thumbsup:

Greg Utas

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.

Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing.

raddevus

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.

Jeremy Falcon

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

Nelek

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.

charlieg

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.

charlieg

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.

Greg Utas

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.

Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing.

David ONeil

"Models are for sissies! Get to work!" :laugh:

Our Forgotten Astronomy | Object Oriented Programming with C++ | Wordle solver

charlieg

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.

jschell

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.

Jeremy Falcon

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

charlieg

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.