What does software engineering look like, in practical terms?
-
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:
to learn how to learn. The rest came with job / life experience.
Same here. 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
-
Duncan Edwards Jones wrote:
Sadly in my experience in a very significant percentage of cases that first step is not taken.
Indeed, it's what I'm seeing happen -- throw some code together, plug in some open source solutions, assume they work correctly, etc. It's all driven by the "we need to get product out the door now." 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 cult of "minimum viable product" strikes again. I usually fall back on the argument - "If this were a medicine would you feel confident in taking it yourself? If this were an airline would you fly with it?" (Again - if this is a treehouse type of project then the medicine is a placebo and the airline is a lego toy)
-
- Gathering customer requirements - Software Architecture - Support concepts (logging, builtin-help etc.) 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.
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
-
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:
how do you practice it in, well, practical terms?
Well basically as you list it up, i go from idea to the lowest block of work / module / codepart. So i start with a big overall architecture, split it up into themed blocks and then reduce those further. I try to fit in patterns and stuff, according to what my product should achieve. Think about security and logging. Make plans and detail all the functions, generate tests and so on. For example i have a big overall (ListOfCustomersProgram), this gets splited into business code (doing the work) dataCode (DBO/Models) and the UI (Usercontrols) and then i split those parts even futher. After connecting the parts i decide where to split into Frameworks / .dll and which parts i can modularize into separate projects. This is just a small part of the whole engineering though :| And that's engineering for me, at least kind of.
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?
We got the modules SoftwareEngineering 1 and 2 so actually i had 2 semesters on dealing with this things. But i can't remember everything we learned there :)
if(this.signature != "")
{
MessageBox.Show("This is my signature: " + Environment.NewLine + signature);
}
else
{
MessageBox.Show("404-Signature not found");
} -
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:
here 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.
They will eventually get the point and learn from it. Last job we were 3 seniors at the end, one was often abroad, the other has no patience, so I got the privilege of teaching the newbies. My first 3 days were just about... naming, commenting, documentation and my list of best practices. Then we got into theoretical aspects of the programing enviroment and the PLC intern structure. Then started with real program examples (my biggest project and the software I was most proud of), I really doubt any of the ones I teached had been confronted to something more exhaustive than that. They all flipped out the first month, but at the end (when I quitted the firm) all came to me and told me different variations of "thanks for kicking my ass at the beginning, it later made my life easier"
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'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
Since developers have no Engineering certifications, it really comes down to how each of us individually define "Software Engineering". For me, even though my job title says "Engineer" and I have 20+ years of experience, I don't consider myself a Software Engineer. Here's the hierarchy I have in my mind: Engineer = Missile Guidance, HFT, Embedded Medical Devices, etc... Developer = LOB applications (order entry, accounting, etc...) <- This is where I am Coder (or Script Kiddie if you prefer) = "Apps" However, having said that, for every missile guidance system out there, there's thousands of "apps". So it makes perfect market-based sense that for every missile guidance Engineer there would be thousands of app Coders.
-
Since developers have no Engineering certifications, it really comes down to how each of us individually define "Software Engineering". For me, even though my job title says "Engineer" and I have 20+ years of experience, I don't consider myself a Software Engineer. Here's the hierarchy I have in my mind: Engineer = Missile Guidance, HFT, Embedded Medical Devices, etc... Developer = LOB applications (order entry, accounting, etc...) <- This is where I am Coder (or Script Kiddie if you prefer) = "Apps" However, having said that, for every missile guidance system out there, there's thousands of "apps". So it makes perfect market-based sense that for every missile guidance Engineer there would be thousands of app Coders.
Vark111 wrote:
Engineer = Missile Guidance
Hi, I'm Denis and I'm an Engineer. I'd LOVE working for Missile Guidance Systems... but I'm stuck with X-Rays. :sigh:
GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X If you think 'goto' is evil, try writing an Assembly program without JMP. -- TNCaver When I was six, there were no ones and zeroes - only zeroes. And not all of them worked. -- Ravi Bhavnani
-
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
For greenfield or brownfield projects, a PM or me will create a high-level project plan. After that fun stuff, I’ll create the following: Architecture Diagram, ERD, ETL Migration (if needed), web page topology, if I have that info, and then we’ll start have meetings. If requirements are easy, me or another developer will run with it. If moderate to very difficult, I’ll do a fully dressed use case. I don’t like user stories as they don’t tell me much, though I have worked in a S**** projects. For the UI, I have sat with the customer and drawn out prototypes on the board or paper or even used post-it notes or viseo diagram by email; so they can visualize and get an idea of how the functionality will work. 15 years ago, undergraduate studies taught me very little about SE. There seems to be one class where we developed test cases; besides that, nothing. In graduate school 10 years ago, I took several software engineering courses that covered UP/RUP, UML, and software development methodologies; we even touched on Agile, Scrum, Crystal, and Lean. I have utilized some RUP tools such as Sequence diagrams and System Sequence diagrams. I see a lot of RUP in today’s tech, just reworded or reworked. I have noticed over the years that many of the best coders or IT people have neglected the software engineering aspect and many times they have a BS to no education.
-
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, 2013And why do you have that opinion about an agile environment? What other alternative do you consider an option?
-
John Simmons / outlaw programmer wrote:
I personally don't think an app can be properly engineered in an agile environment.
Now that opens a door, actually a chasm, which would make for an interesting discussion. Care to elaborate? :) 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
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, 2013 -
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:
4. iterate through 2 to 3 until you've created your product.
And then you end up with a project that doesn't end until someone decides to stop spending money on it (or more unlikely, the customer accepts it).
".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 -
John Simmons / outlaw programmer wrote:
Outlaw Programmer School of Software Development
Is that the "Code first and ask questions later" school?
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
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 -
And why do you have that opinion about an agile environment? What other alternative do you consider an option?
"Agile" is a liberal paradigm. I'm not a liberal.
".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 -
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:
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?
Back when I went to college, they thought that teaching people to program was sufficient. Not even the higher degree classes covered what we do today as software engineering. So, everything I learned about that end of things has been taught to myself, sometimes on the job, but also sometimes not. Incidentally, it isn't just software engineering that's dead, it's all of engineering. Case in point, the Boeing 787 battery[^], wherein the solution wasn't to redesign the battery not to catch fire, but merely vent to the smoke from the fires better. I think the younger generation is so used to building on the shoulders of giants, that they don't realize how much work went into making those shoulders, and therefore think anything that's hard to do doesn't need doing.
We can program with only 1's, but if all you've got are zeros, you've got nothing.
-
raddevus wrote:
4. iterate through 2 to 3 until you've created your product.
And then you end up with a project that doesn't end until someone decides to stop spending money on it (or more unlikely, the customer accepts it).
".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, 2013Yeah, I can see what you mean. Companies mess that up a lot really. A lot of times that's because the decision makers (ones who decide when/how the project ends) don't really understand the product or the process of actually making something. I like the heart of Agile and agility and iterative projects, but I don't like bureaucracy or false and over-inflated processes either. Good talk. :thumbsup:
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
I haven't read all of the replies so far (tl;dr) but I'll cherry pick a couple of points...
Marc Clifton wrote:
when you think of software engineering, how do you practice it in, well, practical terms?
In my experience, an enterprise will hopefully pick the management style somewhere on the specturm from waterfall to agile. There are places where each is correct and the typical answer is somewhere between the 2 extremes. Medical devices and aerospace with well defined requirements should use waterfall. A consumer app with a fickle customer showing lots of feature creep should be agile.
Marc Clifton wrote:
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 started programming in the 1960s. Back then, you learned programming skills using the technology of the day. Computer science is a relatively young technology - arguably about 60 years old - and still evolving today. I have an Engineering degree (EE) and Computer Science degree. My EE training taught me how to think like an engineer. I would guess that about half of the technical skills I have learned have occurred since I graduated. College gives you technical skills but not project management. All management skills (project management and otherwise) I acquired came from life in the real world. One of the metrics that I have found useful over the years is the count of lines of code per man day on a project. When I was in college, I felt I could typically generate about 300 lines of code per day ("man day") for assignments. In the real world, work on a project in a generic app would give about 8-12 lines of code per man day (including developers, testers, project manager). In critical apps such as medical and flight, the number is less than 1 LOC/man day... regardless of the language used. ...The point for this discussion being that different management styles produce different productivity levels, and reciprocally different product quality. [Tangentially, this to me has been part of the justification for use of as high level a language as possible, since both productivity (LOC/man day) and bugs (bugs/KLOC) are relatively constant regardless of the language used.]
I'm retired. There's a nap for that... - Harvey
-
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
Engineering is a mindset that's not available to a fair proportion of people who get paid to program*, so it's really more about where your head is than processes. Engineering is 50% investigation, 35% preparation, and 15% implementation. Those proportions are not always needed for software, true, but they go completely out of the window, when the first thing someone does is sit down and start writing code. * Can we say "euphemism", children?
I wanna be a eunuchs developer! Pass me a bread knife!
-
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.
