What does software engineering look like, in practical terms?
-
As a member of the BCS over here in the UK I remember attending a seminar from a software engineer from the Ministry of Defence who was involved in the development of avionics and navigation software for their jets. And it was eye opening exercise. I had no idea development teams actually used things like Z (the formal programming language) in practice. The level of discipline was far beyond anything I had encountered in real life. Their procedures were extremely disciplined. The key point is that engineering is a set of rigorous disciplines used to build applications. The level to which we employ these disciplines depends on the goals, costs and risks. It takes time, effort, cost and skill to build these sorts of systems. You therefore need to weigh these against the goals. Obviously in avionics, a software bug can lead to a fatality so higher levels of engineering discipline are required than for say a web site. I graduated with a degree in Computer Studies nearly two decades ago where I was taught software design, Z, formal methods, computational mathematics, data structures etc. All of these can be thought of as engineering disciplines.
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare Home | LinkedIn | Google+ | Twitter
Dominic Burford wrote:
I had no idea development teams actually used things like Z
God! You've just brought back such horrible memories! Working for the MoD, that was great -- we had access to any mess we wanted, for our meals (the chiefs and POs' ended up as the favourite, except on Fridays, which was officers' mess all the way). But Z! Logic, my @rse! It has to be the stupidest and most unintuitive way in the world to organise data structures, et al.
I wanna be a eunuchs developer! Pass me a bread knife!
-
I believe he meant to say,
I don't think.
and
An app can be properly engineered in an agile environment.
:laugh: :laugh: Oh, I know I've started a war now. Oh well. :-D Disclaimer I'm just kidding around with the "I don't think" thing. Let's keep it light out there people. :) Honestly, if you understand the heart of Agile -- if you would actually read the book by one of the originally creators of the methodology (Amazon.com: Scrum: The Art of Doing Twice the Work in Half the Time eBook: Jeff Sutherland, Jj Sutherland: Kindle Store[^] ) -- I believe you would find that Agile is really the _ONLY_ way that work gets done. Not only in software development but in other things too. I use the heart of Agile in everything I do. What is the heart? 1. Make a (basic) plan of attack for your project 2. implement the steps in the plan 3. alter the parts of your plan which don't work for reality 4. iterate through 2 to 3 until you've created your product. We who create real things know that plans are not perfect but you have to have one. Methodologies are often over-hyped best practices that people really use and authors have turned into books. However, the real Agile process is quite interesting. But companies (almost) always corrupt it.
My book, Launch Your Android App, is available at Amazon.com.
raddevus wrote:
Agile is really the _ONLY_ way that work gets done
... If EVERYONE is invested in it and EVERYONE wants to pull in the same direction as their colleagues. Many problems a company has with the management of projects can't be cured by Agile.
I wanna be a eunuchs developer! Pass me a bread knife!
-
raddevus wrote:
Agile is really the _ONLY_ way that work gets done
... If EVERYONE is invested in it and EVERYONE wants to pull in the same direction as their colleagues. Many problems a company has with the management of projects can't be cured by Agile.
I wanna be a eunuchs developer! Pass me a bread knife!
Mark_Wallace wrote:
Many problems a company has with the management of projects can't be cured by Agile
100% agree. I'm talking about the actual applied process of : 1. plan 2. follow plan to build pieces of project until done 3. adjust plan according to real life 4. iterate back to 2 and 3 That's all I mean about agile. That is how real work is done. Do companies totally mess that up? Very often, they do. When they get it right -- or a team within the company gets it right -- then the company freaks out and starts saying, we are geniuses who should create a methodology from this great process. And that's when they screw up that good team too. :) When in fact it was just real people doing what has to be really done to get something done. :laugh:
My book, Launch Your Android App, is available at Amazon.com.
-
I personally don't think an app can be properly engineered in an agile environment. I'm self taught (aka, the Outlaw Programmer School of Software Development).
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013John Simmons / outlaw programmer wrote:
the Outlaw Programmer School of Software Development an' shooten irons
Typical developer. Always forgets vital information in the documentation.
I wanna be a eunuchs developer! Pass me a bread knife!
-
On the job - my University concentrated on teaching you the language, and some algorithms / in depth design (such as compiler design, OS design) without trying to instill the right "mind set" you need to "development as an engineering science" as opposed to "development as an artform". For what I see in QA, nothing have changed in that respect - except the in depth stuff has vanished in favour of "how to use FarceBook in VB" :sigh:
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
OriginalGriff wrote:
except the in depth stuff has vanished in favour of "how to use FarceBook in VB"
You've got that damned right.
I wanna be a eunuchs developer! Pass me a bread knife!
-
I'm actually thinking of writing an article entitled "Software Engineering is Dead", but I want to ask y'all, when you think of software engineering, how do you practice it in, well, practical terms? Anything from doing detail design analysis, prototypes (that don't turn into production code), design patterns, high level architectures like messaging, pub/sub, modular, service oriented, async, etc., all are fair game for what, in practice, "engineering" looks like. (Note how I snuck the idea of "high level architecture" into the idea of "engineering".) I'm also curious, for those with some level of college degree, did college teach you engineering skills, or did you learn them yourself or on the job? Marc
Imperative to Functional Programming Succinctly Contributors Wanted for Higher Order Programming Project! Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
Software engineering is dead - Actually Software engineering doesn't exist for scripting language like JavaScript, Python , Ruby. Has never worked from entire experience. Time estimation, analysis , design everything is just pain for delivery. Software Engineering does really work well for primarily created as Typed, OOD based languages like Java, C++, C# , ... Off course there will be a heavy duty along doing it so. One question though, how they are doing things like pub/sub in script language. It just a puzzle to me as of now.
-
I'm actually thinking of writing an article entitled "Software Engineering is Dead", but I want to ask y'all, when you think of software engineering, how do you practice it in, well, practical terms? Anything from doing detail design analysis, prototypes (that don't turn into production code), design patterns, high level architectures like messaging, pub/sub, modular, service oriented, async, etc., all are fair game for what, in practice, "engineering" looks like. (Note how I snuck the idea of "high level architecture" into the idea of "engineering".) I'm also curious, for those with some level of college degree, did college teach you engineering skills, or did you learn them yourself or on the job? Marc
Imperative to Functional Programming Succinctly Contributors Wanted for Higher Order Programming Project! Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
-
Marco Bertschi (SFC) wrote:
Gathering customer requirements
An often forgotten step.
Marco Bertschi (SFC) wrote:
Software Architecture
But what is that? How do you (specifically you) go about doing that?
Marco Bertschi (SFC) wrote:
Support concepts (logging, builtin-help etc.)
Aye, logging. The architecture that I was using, courtesy of the pub/sub system I wrote, logs to wherever (PaperTrailApp being a favorite) and exceptions are caught and emailed to me (quite fun when that's in place at that get go.)
Marco Bertschi (SFC) wrote:
All that and many more are software engineering, and in some terms even Usability Engineering (at least part of it) could count in as being a part of Software Engineering.
Hmm, Usability Engineering, there's something to think about. What about "Maintainability Engineering" -- writing the code so that other programmers can easily understand it? There seems to be a tension there that I encounter a lot, particularly with junior devs, who really don't understand well enough the language (C#), the framework (.NET), and the architectural decisions that the senior developer (moi) made. Marc
Imperative to Functional Programming Succinctly Contributors Wanted for Higher Order Programming Project! Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
Marc Clifton wrote:
Marco Bertschi (SFC) wrote:
Software Architecture
But what is that? How do you (specifically you) go about doing that?
Data Streams, Business rules and customer restrictions (e.g. "Can't be connected to t'internet") and so on. At the moment we use an approach where we have our Entity Data Model encapsulated by a Business Domain Model, where a Shared Business Layer handles access to the entity framework and only displays Business Model objects to the top.
-
Marco Bertschi (SFC) wrote:
Gathering customer requirements
An often forgotten step.
Marco Bertschi (SFC) wrote:
Software Architecture
But what is that? How do you (specifically you) go about doing that?
Marco Bertschi (SFC) wrote:
Support concepts (logging, builtin-help etc.)
Aye, logging. The architecture that I was using, courtesy of the pub/sub system I wrote, logs to wherever (PaperTrailApp being a favorite) and exceptions are caught and emailed to me (quite fun when that's in place at that get go.)
Marco Bertschi (SFC) wrote:
All that and many more are software engineering, and in some terms even Usability Engineering (at least part of it) could count in as being a part of Software Engineering.
Hmm, Usability Engineering, there's something to think about. What about "Maintainability Engineering" -- writing the code so that other programmers can easily understand it? There seems to be a tension there that I encounter a lot, particularly with junior devs, who really don't understand well enough the language (C#), the framework (.NET), and the architectural decisions that the senior developer (moi) made. Marc
Imperative to Functional Programming Succinctly Contributors Wanted for Higher Order Programming Project! Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
Marc Clifton wrote:
Hmm, Usability Engineering, there's something to think about.
I did the Foundation Level (CPUX-F) - International Usability and UX Qualification Board[^] a few months ago. IMO at least a basic udnerstanding of usability should be part of every developers epxerience (except maybe embedded programmers :-\ ). If you want my 5 cents on Usability Engineering in the article drop me a PM.
-
I'm actually thinking of writing an article entitled "Software Engineering is Dead", but I want to ask y'all, when you think of software engineering, how do you practice it in, well, practical terms? Anything from doing detail design analysis, prototypes (that don't turn into production code), design patterns, high level architectures like messaging, pub/sub, modular, service oriented, async, etc., all are fair game for what, in practice, "engineering" looks like. (Note how I snuck the idea of "high level architecture" into the idea of "engineering".) I'm also curious, for those with some level of college degree, did college teach you engineering skills, or did you learn them yourself or on the job? Marc
Imperative to Functional Programming Succinctly Contributors Wanted for Higher Order Programming Project! Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
This topic is depressing. I recently fell into consulting because I couldn't get a job. I tell prospective employers: I'm not a rockstar, I'm not a coding ninja, I'm old/pedantic/thorough and therefore slow. I'm not a senior developer, I've only been doing development for about 8 years now (4 years embedded C, 4 years iOS). I don't like Agile (enabler of rockstar haxors and script-kiddies) so I'm not *gasp* a team-player. I have no formal training except for about 3 months fulltime, pre-2000. The thing is, during those 3 months our instructor gave us little extra exercises, and I went home and did them. I showed him my code, very puffed up as you can imagine. He rewrote my 20+ line function in about 5 lines, with 2 nested loops. Mind blown. :wtf: I learnt that there is always a better, more elegant way to do something, and I've been trying to achieve it ever since. So I read about best practices, design principles, architecting, becoming a better programmer (which is why I'm on this site :-\ ). In embedded development I learnt there are no shortcuts. You really need to architect your stuff properly, because it's going to grow like a fungus in a dung heap. And the POC you're told to do today is sold as a feature tomorrow, so just do it properly and save yourself a lot of pain. It seems to be an older mindset, wanting to improve and do better with every project, and build something lasting (or as lasting as software can be). Whereas the younger developers seem to want to learn every new, sexy language, but just enough for "Hallo World", and play with fun new technologies. Build it today, throw it out for the next thing tomorrow. This instant-developer-just-add-beer world isn't for me :sigh:
-
Dominic Burford wrote:
I had no idea development teams actually used things like Z
God! You've just brought back such horrible memories! Working for the MoD, that was great -- we had access to any mess we wanted, for our meals (the chiefs and POs' ended up as the favourite, except on Fridays, which was officers' mess all the way). But Z! Logic, my @rse! It has to be the stupidest and most unintuitive way in the world to organise data structures, et al.
I wanna be a eunuchs developer! Pass me a bread knife!
Mark_Wallace wrote:
It has to be the stupidest and most unintuitive way in the world to organise data structures, et al.
But.......it is mathematically provable, and that's the point. I must admit I found Z to be intuitive as it aligns with mathematics.
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare Home | LinkedIn | Google+ | Twitter
-
I believe he meant to say,
I don't think.
and
An app can be properly engineered in an agile environment.
:laugh: :laugh: Oh, I know I've started a war now. Oh well. :-D Disclaimer I'm just kidding around with the "I don't think" thing. Let's keep it light out there people. :) Honestly, if you understand the heart of Agile -- if you would actually read the book by one of the originally creators of the methodology (Amazon.com: Scrum: The Art of Doing Twice the Work in Half the Time eBook: Jeff Sutherland, Jj Sutherland: Kindle Store[^] ) -- I believe you would find that Agile is really the _ONLY_ way that work gets done. Not only in software development but in other things too. I use the heart of Agile in everything I do. What is the heart? 1. Make a (basic) plan of attack for your project 2. implement the steps in the plan 3. alter the parts of your plan which don't work for reality 4. iterate through 2 to 3 until you've created your product. We who create real things know that plans are not perfect but you have to have one. Methodologies are often over-hyped best practices that people really use and authors have turned into books. However, the real Agile process is quite interesting. But companies (almost) always corrupt it.
My book, Launch Your Android App, is available at Amazon.com.
I used to be pro agile, I am starting to have reservations though. John is correct with his simple one line comment on Agile. I have seen more projects fail on Agile - in the end , then not - usually to a hodge podge design process (especially during maintenance enhancements) during agile, where everyone is climbing out of their ass to get the work done in the allotted sprint, usually the work is shit, but as you said, it gets done...but it is still stinky pile of shit. No, Agile is not the answer. Perhaps a mutation of Agile (there are many) is the answer, one can only hope.
-
In an agile environment (at least every one I've had the misfortune of being part of), all code is seat-of-the-pants this-might-work we'll-fix-it-later kinda stuff. Nothing is written down as far as how components interact, so "sh|t gets done when you get around to it". Inheritance chains usually end up being a quagmire of crap, code is needlessly duplicated, is lacking in comments and/or documentation, and "elegant" is never an appropriate description of the code. This makes it a freakin nightmare to maintain, and since this is the way it happens more often than not, nobody in their right mind would want to come in cold and work on it. The possibility of bug "fix" side effects are both subtle and wide-ranging, and to be honest, new programmers have almost ZERO debugging skills. Maybe I'm just not a believer in the agile paradigm when an enterprise-level mission-critical application is under development. SDLC with a reasonable timeline for completion all the way, and don't skimp on hiring the necessary talent.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013Well said. This has been my experience as well.
-
I believe he meant to say,
I don't think.
and
An app can be properly engineered in an agile environment.
:laugh: :laugh: Oh, I know I've started a war now. Oh well. :-D Disclaimer I'm just kidding around with the "I don't think" thing. Let's keep it light out there people. :) Honestly, if you understand the heart of Agile -- if you would actually read the book by one of the originally creators of the methodology (Amazon.com: Scrum: The Art of Doing Twice the Work in Half the Time eBook: Jeff Sutherland, Jj Sutherland: Kindle Store[^] ) -- I believe you would find that Agile is really the _ONLY_ way that work gets done. Not only in software development but in other things too. I use the heart of Agile in everything I do. What is the heart? 1. Make a (basic) plan of attack for your project 2. implement the steps in the plan 3. alter the parts of your plan which don't work for reality 4. iterate through 2 to 3 until you've created your product. We who create real things know that plans are not perfect but you have to have one. Methodologies are often over-hyped best practices that people really use and authors have turned into books. However, the real Agile process is quite interesting. But companies (almost) always corrupt it.
My book, Launch Your Android App, is available at Amazon.com.
-
Mark_Wallace wrote:
It has to be the stupidest and most unintuitive way in the world to organise data structures, et al.
But.......it is mathematically provable, and that's the point. I must admit I found Z to be intuitive as it aligns with mathematics.
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare Home | LinkedIn | Google+ | Twitter
Hey, I don't need mathematical proof that a light switch works to enable me to switch on the light. If you want people to find creative solutions to problems, it's better to abstract them well away from the world of Z -- but that's probably why the military likes it; "creative" is a bad word, in the military (with good reason, though. Following "The Book" is much less likely to get you and your mates killed).
I wanna be a eunuchs developer! Pass me a bread knife!
-
I used to be pro agile, I am starting to have reservations though. John is correct with his simple one line comment on Agile. I have seen more projects fail on Agile - in the end , then not - usually to a hodge podge design process (especially during maintenance enhancements) during agile, where everyone is climbing out of their ass to get the work done in the allotted sprint, usually the work is shit, but as you said, it gets done...but it is still stinky pile of shit. No, Agile is not the answer. Perhaps a mutation of Agile (there are many) is the answer, one can only hope.
Slacker007 wrote:
have seen more projects fail on Agile - in the end , then not
This is a danger because work often continues without oversight of how it actually impacts the project overall. That's because Common Sense is supposed to be built-in. I know. I know. Common Sense isn't so common. Think of the entrepreneur-developer who is creating a thing and s/he is building it. Making it better each day, each change, each item in the work. Hopefully that dev has some true architectural skills so when the product is complete it isn't a brittle piece of garbage. However, I know how companies/corporations/teams work. People along the way are like, "hey what am I supposed to do?" Then later, "Okay I did my thing." But then their contribution to the project stops there. "Hey, I did what I was supposed to do." Agile provides a lot of nooks and crannies for things that are specifically assigned to fall into. The project moves forward and the whole becomes less than what everyone hopes. All because no one iterated through to actually fix the stuff to make it usable. It's a challenge.
My book, Launch Your Android App, is available at Amazon.com.
-
your heart of Agile - looks a lot like Iterative methodolgy, which I understood to be a bit differnt in approach then Agile?
maze3 wrote:
your heart of Agile - looks a lot like Iterative methodolgy, which I understood to be a bit differnt in approach then Agile?
Interesting. I guess you'd have to read the book I mentioned for us to see where we are on this. If you read it I'd be happy to discuss where I'm off the path. :) I don't know. "Agile" has been described many places in many ways, but the author is one of the original creators of the methodology. Of course I could be understanding it entirely differently from his explanation too.
My book, Launch Your Android App, is available at Amazon.com.
-
I'm actually thinking of writing an article entitled "Software Engineering is Dead", but I want to ask y'all, when you think of software engineering, how do you practice it in, well, practical terms? Anything from doing detail design analysis, prototypes (that don't turn into production code), design patterns, high level architectures like messaging, pub/sub, modular, service oriented, async, etc., all are fair game for what, in practice, "engineering" looks like. (Note how I snuck the idea of "high level architecture" into the idea of "engineering".) I'm also curious, for those with some level of college degree, did college teach you engineering skills, or did you learn them yourself or on the job? Marc
Imperative to Functional Programming Succinctly Contributors Wanted for Higher Order Programming Project! Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
Marc Clifton wrote:
prototypes (that don't turn into production code)
Ba-ha-ha-ha-ha! As if! Just kidding, Marc. To be fair, I have a very rational (from a tech standpoint) partner on the business side. He understands and is good with us iterating on bigger things. We'll often discuss some project, and figure out good milestones where we can release, and give some improvements, all the while moving toward our ultimate goal. I find this approach also helps when he gets the (almost) inevitable push to change priorities. Then we have project #1 in a spot we set aside (or close to, and get to the next milestone), and move to project #2.
Marc Clifton wrote:
I'm also curious, for those with some level of college degree, did college teach you engineering skills, or did you learn them yourself or on the job?
I think I went to college far too long ago for this to apply too much. Even then, most of what I think most people consider my strong points are specifics learned on the job, but generally just part of my personality (detail oriented, enjoying figuring out a solution to the problem).
-
I'm actually thinking of writing an article entitled "Software Engineering is Dead", but I want to ask y'all, when you think of software engineering, how do you practice it in, well, practical terms? Anything from doing detail design analysis, prototypes (that don't turn into production code), design patterns, high level architectures like messaging, pub/sub, modular, service oriented, async, etc., all are fair game for what, in practice, "engineering" looks like. (Note how I snuck the idea of "high level architecture" into the idea of "engineering".) I'm also curious, for those with some level of college degree, did college teach you engineering skills, or did you learn them yourself or on the job? Marc
Imperative to Functional Programming Succinctly Contributors Wanted for Higher Order Programming Project! Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
I have written many articles on the lack of actual software engineering practices in software shops. They may help you with some of your thoughts on your upcoming article. You can see all of my articles at the following link... https://blackfalconsoftware.wordpress.com
Steve Naidamast Sr. Software Engineer Black Falcon Software, Inc. blackfalconsoftware@outlook.com
-
maze3 wrote:
your heart of Agile - looks a lot like Iterative methodolgy, which I understood to be a bit differnt in approach then Agile?
Interesting. I guess you'd have to read the book I mentioned for us to see where we are on this. If you read it I'd be happy to discuss where I'm off the path. :) I don't know. "Agile" has been described many places in many ways, but the author is one of the original creators of the methodology. Of course I could be understanding it entirely differently from his explanation too.
My book, Launch Your Android App, is available at Amazon.com.
Just a curious question here but how many years of continuous Agile experience do you have? The reason I ask is you sound very pumped up about it, and anyone who has worked with it religiously, is usually not pumped up about it. --> my experience. Just curious...
