|
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.
|
|
|
|
|
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" 
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
OriginalGriff wrote: except the in depth stuff has vanished
I've noticed that. 30 years ago, my friend was graduating from UCSD with a degree in computer science, and everything he knew that was practical he had learned himself, particularly, modern (at the time) languages, tools, hardware, etc.
30 years later, I'm talking to a graduate of U. of Tennessee and the poor kid hasn't had any school exposure to languages like C#, and no exposure to modern tools (IDE's, debuggers, etc), again, anything he's learned he has learned on his own.
Marc
|
|
|
|
|
Marc Clifton wrote: the poor kid hasn't had any school exposure to languages like C#, and no exposure to modern tools (IDE's, debuggers, etc), again, anything he's learned he has learned on his own.
Honestly I think it's a plus. Learning how to think, how to write algorithms and the hard science is more important than leanring the usage of tools. A properly trained mind can master any tool in a reasonable amount of time, even after paradigm shifts ot big technological changes. An ignorant mind who's been trained only in the use of some tools won't be able to adapt as easily. Of course every person is a world in itself so it's a GENERAL consideration.
It's not the Education System that has to teach jobs for the companies, that is responsibility of the companies themselves. The Education System must create people, with the skills and mindset to approach their trade and life itself.
In Italy we have Professional Schools, they are high schools that teach 5 years straight a trade, and we have Technical Schools, which are basically light engineering (up to 30 years ago the graduated students from those high schools were officially named Junior Engineers, with legal value). At the Technical University I (coming from a Technical high school) had the chance to confront with students coming from Professional Schools: they looked like monsters. They knew all the current tools and were able to quickly put up some sort of working... things. But they weren't able to design a simple algorithm or to learn plain C, because they were only trained to use a couple of languanges... of which they botched the exams. And they were anything but stupid, mind you.
It's also the biggest chasm between Computer Science and Computer Engineering, at least in my city. CS students exit with many, many more "current" skills than us in CE. And quickly lose value and adaptability over the next 5-10 years. Our Technological University clearly stated that their most radicated goal is to make us as much tool-independent as possible.
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
|
|
|
|
|
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 sure the spirit of the article won't be as of this discussion[^]
Quote: did college teach you engineering skills
Yes but that would be basic. But most knowledge comes from applying on a real work environment and building your experience from project to project.
Wonde Tadesse
|
|
|
|
|
I keep seeing these posts here about software engineering is dead, developers don't exist anymore, yadda yadda.
I have absolutely no idea what the blazes you guys are talking about. I've been a software engineer for 33 years and we are more busy now than ever before. It's insane we are so busy. Yes, developing systems in C# and SQL, and 100 other technologies linked together. We have to force ourselves to stop for most of today in order to interview 3 new candidates to join the team.
The entire world is now software. Even my car runs on software. Software engineers are gods.
As for your other question, I studied electrical engineering. Every single thing about systems and application design I taught myself, or from mentors. I have never stopped learning new things and exploring new technologies. When I get home, I switch to my home projects, mostly involving security, home automation, video streaming, communications, avionics... I try to sleep once in a while.
|
|
|
|
|
I get the feeling that Marc's post has less to do with software engineering being dead and more to do with the cult of the script kiddies who seem to want to jump onto the latest shiny, rather than applying rigour and discipline to build and maintain systems. Marc has just been through a particularly bruising application of this where a well engineered system has been cast aside to allow the children to write a new Python based one, from scratch, simply because they have the CTO's ear.
This space for rent
|
|
|
|
|
Got it. I see that too. You have swarms of high-schoolers who are only interested in writing games for iOS. But we've had that kind of people in our midst since the beginning. Important systems running on big hardware still run the world. I laugh at people who say the iPhone is replacing the desktop. If anything, I want my desktop system to be even more powerful. My friend just added a 43 inch monitor to his development workstation. I don't see myself sitting in a corner building systems on a 4.5 inch phone. Can you imagine doing AutoCAD drawings of a space station on an iPhone? I can't.
Don't get me wrong, those toys are really cool, and I use one myself. But that doesn't take away from the real data processing needs of the world. And the infrastructure that runs those millions of iPhones are not running on little iPhones. They are running on real hardware. Built by real engineers.
|
|
|
|
|
If you send me a picture of yourself I'll start building your statue right away.
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
|
|
|
|
|
Pete O'Hanlon wrote: Marc's post has less to do with software engineering being dead and more to do with the cult of the script kiddies who seem to want to jump onto the latest shiny, rather than applying rigour and discipline to build and maintain systems.
Two sides of the same coin.
Pete O'Hanlon wrote: to allow the children to write a new Python based one, from scratch, simply because they have the CTO's ear.
The irony here is that because of hardware and browser hosting issues, Python got thrown out (I think) and it's being rewritten in F#.
More irony. Particularly since the only junior guy, while he has FP experience, has never used F# and I had to tell him "if you use the debugger, you'll see that your property assignment isn't working because you need to use the <- operator to make an assignment to a mutable structure, not the = operator.
Marc
|
|
|
|
|
You can't blame the "children" for that, they didn't make that decision. The CTO did. And calling them "children" is probably a little patronising, we were all young once.
"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
|
|
|
|
|
Basildane wrote: I've been a software engineer for 33 years and we are more busy now than ever before. It's insane we are so busy.
But that's point -- you're an engineer because you have 33 years of experience. But it seems that very few people, particularly (as Pete pointed out the motivation for my post) young script kiddies and CTO's that think they're programmers because they coerce a few open source projects to work together to build a website.
Colleges/universities don't seem to teach engineering skills, managers freak out when you write code that uses a publisher/subscriber pattern, and Agile (in the ways I've seen it implemented) doesn't give a sh*t about up front design.
Marc
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
