But then it wouldn’t be called “hacking”, and so wouldn’t pass as software development these days. Instead, let’s have no planing whatsoever, no design and no requirements, have minimal time for actual development, “hack” code together and see where bugs take us. Aka “scrum”, “agile” and whatnot.
I feel like the problems you describe here (constantly changing requirements, minimal time for development, "hacking" code together) have less to do with agile methods and more with people-stuff.
I think agile methods can help a great deal in software development, especially breaking apart your projects into more discreet steps and supervising progress or giving the possibility for correcting course via sprints. Also using eXtreme programming tools like pair programming or code reviews to avoid having people slip into a frenzy of their individual domain / help keep obvious bugs out.
Having minimal time and changing requirements is just part of the game. And people "hacking" code together is just... well bad craftsmanship really
Agile methods are people stuff. Agile is just another management strategy.
Standard engineering design breaks projects into discrete steps, it's not at all unique to Agile. Doing that is essentially the definition of "work breakdown structure". Course correction time is built into Gantt charts. Engineers have had to deal with constantly changing requirements, minimal development time, etc, since long before software came around. They're further constrained because you can't just ship a patch to a bridge or plane after it's completed. And yet they manage to get reliable, functional work done!
Agile is management with ADD. Waterfall is a straw man process that no competent organization would use.
>>using eXtreme programming tools like pair programming or code reviews to avoid having people slip into a frenzy of their individual domain / help keep obvious bugs out.
Wtf does this even mean? What are you talking about. If the bugs are obvious why do you need extreme programming to find them? What frenzy? Extreme programming is garbage.
From my experience, when a proper preparation is done and there are clear requirements, most of the "obvious" bugs do not even come into play. They do, when "hacking" a feature and / or working in "POC" mode, which, for me, is not software engineering.
For me it isn't either and I'm certainly not advocating for "hacking" features together. The obvious bugs I mentioned were not design bugs, but simple slips that creep in when you've already worked for a few hours and your attention starts lacking.
>If the bugs are obvious why do you need extreme programming to find them
Because sometimes you've already worked for a few hours and end up wasting time with stuff, which could have been spotted easily by help of a fellow developer.
>What frenzy?
The frenzy I was talking about was referring to working on a project for weeks on end and forgetting that of course you are now skilled in that domain you built yourself, but at some point other people will have to work with that system too and for them your answers might not be that obvious. Having other people check in regularly can prevent this.
Also, please don't 'wtf' me, you could have just as easily framed your question in a more humane way. I wasn't trying to defend extreme programming here, but merely stating that a focus on open communication will lead to more robust software. Don't abuse my comment for furthering your personal hate against some software development methodology.
Do you ever get the feeling that software "engineers" are expected to be little more than business-ops guys with a higher IQ and a habit of unusual fascination with solving problems that must be done in tiny detail?
