|
Don't ask me, I am a Klingon Developer.
Someone, however thinks it is 'anything helpful to cope with the mess'. So, above all, well documented (or at least heavily commented) API, then, yes, prototyping and testing, and possibly design for testing.
|
|
|
|
|
CPallini wrote: I am a Klingon Developer
You haven't programmed until you've written something in Klingon Basic! 
Marc
|
|
|
|
|
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, 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
|
|
|
|
|
Tell me the problem you want to solve and then leave me alone to do the job. Precisely.
Software Zen: delete this;
|
|
|
|
|
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
|
|
|
|
|
I believe he meant to say,
I don't think.
and An app can be properly engineered in an agile environment.
Oh, I know I've started a war now. Oh well. 
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.
|
|
|
|
|
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
|
|
|
|
|
Yeah, 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.
|
|
|
|
|
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.
|
|
|
|
|
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 sh*t, but as you said, it gets done...but it is still stinky pile of sh*t.
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.
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
Wow, all of that and you still did not answer my question. 
Nevermind...
|
|
|
|
|
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
|
|
|
|
|
Well said. This has been my experience as well.
|
|
|
|
|
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
|
|
|
|
|
John 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!
|
|
|
|
|
I 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.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
