What does software engineering look like, in practical terms?
-
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...
-
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 attended college but it was mostly Computer Science. The engineering part came by experience. :-D :laugh: Go, write your book, it's always welcome. Please tell us when it's in print to buy it :)
-
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...
I have been developing software since 1995. I have been on projects that are not managed, mis-managed, large projects which ultimately spent $75 million on development and then failed (large mortgage bank) and small projects where I play every role in the process (BA, architect, programmer, qa, support) to get an app into production. Again, I know that companies use methodologies as buzzwords and beat their employees with them. I am saying that Agile is a cool iterative process that can (if properly done) expose things earlier and build community within the dev team (including QA, support, PM, etc) but alas it is often done improperly. You must have a very strong and intelligent, gracious, experienced development manager who has real software design and architecture experience for it to go well. I have such a person in that role now. Although, in the over 23 years I've been developing software before this have not had such a person. They are rare animals and without them every methodology ends up failing. And even in an environment which is lead by such a person, agile can fail because a team may be racing in the sprint and fixing other things isn't so fun and we all just want to run to dev the next new thing. However, I would say that with an experienced overseer they will see that happening (we are here) and understand that we have to clean things up before moving on. But beyond all that, I love the work process of the basic agile flow. It works great for single developer projects. That's where real work is done. Great discussion by the way.
My book, Launch Your Android App, is available at Amazon.com.
-
I have been developing software since 1995. I have been on projects that are not managed, mis-managed, large projects which ultimately spent $75 million on development and then failed (large mortgage bank) and small projects where I play every role in the process (BA, architect, programmer, qa, support) to get an app into production. Again, I know that companies use methodologies as buzzwords and beat their employees with them. I am saying that Agile is a cool iterative process that can (if properly done) expose things earlier and build community within the dev team (including QA, support, PM, etc) but alas it is often done improperly. You must have a very strong and intelligent, gracious, experienced development manager who has real software design and architecture experience for it to go well. I have such a person in that role now. Although, in the over 23 years I've been developing software before this have not had such a person. They are rare animals and without them every methodology ends up failing. And even in an environment which is lead by such a person, agile can fail because a team may be racing in the sprint and fixing other things isn't so fun and we all just want to run to dev the next new thing. However, I would say that with an experienced overseer they will see that happening (we are here) and understand that we have to clean things up before moving on. But beyond all that, I love the work process of the basic agile flow. It works great for single developer projects. That's where real work is done. Great discussion by the way.
My book, Launch Your Android App, is available at Amazon.com.
Wow, all of that and you still did not answer my question. :doh: Nevermind...
-
Precisely. Give me the specs, and go away. I'll let you know when it's finished.
".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, 2013:thumbsup: Tell me the problem you want to solve and then leave me alone to do the job. Precisely.
Software Zen:
delete this; -
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
The Software Engineering Institute at Carnegie Mellon Institute had a long history of attempting to justify the application of "engineering" to software development through the Capability Maturity Model. The model recognized that software, as a developing discipline, lacked the "best practices" and "working methods" that allowed older engineering disciplines to create qualification exams. So the CMM codified management practices that would allow organizations to discover and document those practices and methods. This was all swept away in the internet craze and economies of scale driven by zero cost of distribution. Software engineering practices are the competitive advantage that keeps Microsoft and Google and Amazon in the money, and they are not likely to surrender them. This is evidenced by the surrender of IP to open source. It doesn't make a difference whether you can get the code if you don't have the discipline to do a thorough V&V of the product as a whole - nobody spending cash money is going to trust what you wrote. Where this has led, in the C# world, is to a steady drip of language features that allow coders to do their work faster. This manifests in (C#) attributes in the persistence framework and keywords that simplify threading and make properties behave like public (class) attributes . The upshot is that hackers can hack faster (including thinking of asynchronous processing as sequential logic) because Microsoft does the engineering behind the scenes to ensure that signals are produced and work-arounds available when something unexpected happens. The paradox that should be recognized is that the engineering is organized to allow most developers to avoid engineering. Except in control systems, time-to-market is king, and the APIs provided by the major players ensure that application failure results in lost business, and not consumer fraud. Eventually this will work its way out, because ultimately its engineering practices that allow IP to carry over from generation to generation. It's only those companies that do engineering that will survive the retirement of their lead developers.
-
Marc Clifton wrote:
how do you practice it in, well, practical terms?
Someone assigns tasks during a sprint.
Marc Clifton wrote:
for those with some level of college degree, did college teach you engineering skills
Schools are there to make sure you become obedient, not to convey knowledge.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^][](X-Clacks-Overhead: GNU Terry Pratchett)
I would contend that colleges are designed to teach problem solving, in general. They are a way of transitioning from the "rigid tell me what to do" of public high schools to the "you're on your own" mentality of modern business. Some are able to put those pieces together themselves without college. Some will never understand where to start solving a problem no matter how long they might be in school. For most, however, college guides the graduates to become self-motivating and, more importantly, self-sufficient. I would agree, and argue that it is a positive thing, that colleges do not teach what businesses want. Such information is transitory while the skills that college teaches are permanent.
-
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 only consider 8 or 9 subjects (from over 40) that teached me something that have been really usefull and have been using a while in work life. At the beginning I was trying to learn a lot of stuff and got overwhelmed. Was never happy with my results and eventually got demotivated. After a time and one sommer job as electical monteaur I changed my mind and started paying way more attention to (what others already mentioned) the methodes and less to the concrete contents. I experienced an increase of my confidence and I started to feel good with it. Later on I just learned specifics enough to pass the exam. I don't remember 90% of the formulas and other concrete staff, but give me a problem of the lessons, a book related or the internet and I will be solving it after a while. So as conclusion I would say: The most important lesson I got from college was... to learn how to learn. The rest came with job / life experience.
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.
Nelek wrote:
So as conclusion I would say: The most important lesson I got from college was... to learn how to learn. The rest came with job / life experience.
Well stated; you have succinctly described the true purpose of college.
-
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, You pose an interesting question, and the answer is... Id Depends... Okay, for smaller pieces we gather the core requirements and iteratively get things finished. For more complicated ones, we actually split it up into pieces, and then apply engineering concepts ONLY where needed (are we use MQ, enquue, or our ownque). Leveraging previously well working designs (kinda like using patterns), but we do NOT share the code, we copy it (unless we already made a library). Sometimes we shoehorn a solution into something we already have working (leveraged an existing DB that the clients had access to, but now for a different project, which turned out to be useful later in the project when they actually needed to show some of that data!). The goal is KISS. Can I explain it in 30 seconds. Can anyone identify the single points of failure? How resilient does it have to be? (If it goes down, will it halt production on the floor). Then, each box is treated appropriately. Many solutions are NEVER a single EXE. We often have daemons, services, GUI/Clients, and intranet/html. We apply different levels of engineering to different layers. We mandate logging, and indications if we are running in Production, Staging, Test or Developer environments. We apply code reviews, and sharing of best practices (removal of worse practices). Did I learn any of this in College? Yes. In fact, my late professor challenged me to write a simple program: Add 2 numbers. And then guarantee it's correctness. Warning me that I was not allowed to make any implied assumptions. All assumptions had to be stated. (Both numbers had to be integers in the range of 32 bit integers, and adding them together cannot exceed a 32 bit integer, etc. etc. etc). And I failed. I Falsely assumed the hardware would add correctly, without listing it as an assumption. I argued that was unfair. A few months later the Pentium F-Div bug showed up. And he rubbed my nose in it. (BTW, they built a computer, he was on the team, and they had a cold soldering joint on one of the data wires, and it was causing the math to behave funny, which is why he uses it as an example). In the process, I was taught to think WAY BEYOND my software. I find it incredibly helpful. And I have had the experience that Power has been questionable, Hardware has issues, the definition of daylights savings time changes, and upgrades cause old working code to suddenly break. We work on a layer of assumptions that is simply asto
-
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
It's not dead. Just resting... The root book of the software engineering movement is (IMHO) Fred Brooks' The Mythical Man Month. He wrote that book about experiences he had in 1967, and spawned a whole sub-discipline of computer science. Only, we still haven't learned the lesson fully. Do developers always use all available tools from software engineering? No, don't be silly. Do mechanical engineers do a stress analysis on every box they design? No. Why should they? Well, should they? Yeah, sometimes. People rush right to coding for a variety of reasons; they think the problem is easy. Their manager is pressuring them to produce. They're human beings, who are lazy when they can be. It doesn't matter to customers if the code works right every time. But the fact that some devs are lazy and some managers are ignorant hardly means software engineering is dead. Somebody is writing software for space probes, commercial aircraft, and nuclear reactors. And these things fail less frequently than they used to. Some web sites have performance so rock-solid that you don't even think about them going down. These are places where software engineering is being practiced. People whine about how these companies are so bound up in process that it's impossible to get anything done...anything, that is, but rock-solid quality code.
-
Nelek wrote:
So as conclusion I would say: The most important lesson I got from college was... to learn how to learn. The rest came with job / life experience.
Well stated; you have succinctly described the true purpose of college.
Thanks :)
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.
-
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, 2013I think it sort of depends on what part of a system you are developing. The backend data and logic probably needs to be more carefully thought out and designed ahead of time, whereas the front-end and its user-based workflow can usually be "agile". Giving the client to actually try out the UI and make changes to better suit their needs is helpful, before going to far down a wrong path. I remember working on a contract with a small team of developers, and they were determined to do everything "agile" (and had no previous experience). I was responsible primarily for the back end, and it seemed that after every 2-3 sprints they introduced a new "story" where I ended up having to refactor huge amounts of the code. Again if they had a better idea of what the long term needs/requirements were, I could have design this with these features in mind.
-
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
You can't call it engineering until some objective measures can be applied to the whole endeavour of software development; of which there are very few. Mathematics and science does factor in some ways (e.g. code metrics or relative performance of algorithms) but taken out of context of requirements, design and success - in the business sense - not that much help. To put it another way, there is no way to observe an existing project and predict it's outcome, even with a margin of error. You can't observe a software developer and objectively measure their performance either. Nor can you apply any true measure to a team. To describe software engineering as dead, misses the point. It never was alive as an engineering discipline because the basics have never been discovered let alone applied. At the moment it is an artistic endeavour. The best analogy I've come across is the comparison to a team sport where science helps, but cannot fill in for the human factors. Frustratingly I'm not an academic so I'm not familiar with any formal studies, but I do know some are being made. However, the studies I have read about don't, IMHO, control the myriad of variables correctly or mitigate them through wide statistical sampling. Not convinced they are asking the right questions either. If I ever had the opportunity I would perform a range of studies to try and uncover some fundamental truths about software development. For prosperity here is a list of studies I would like to see done; 1. TDD vs non-TDD 2. How effective is refactoring? 3. Does documentation help a new developer? 4. Is pair programming more effective than lone development? 5. Is it better to learn through documentation or pair programming? 6. How accurate are comments? 7. Is bug fixing more expensive than good design? 8. Is untidy code more fault prone? 9. Are some requirements more error prone than others?