SoylentNews is people
SoylentNews
from the what-if-you-can't-program-your-way-out-of-a-paper-bag? dept.
Agile Development is hip. It's hot. All the cool kids are doing it.
But it doesn't work.
Before I get into why this "Agile" stuff is horrible, let's describe where Agile/Scrum can work. It can work for a time-sensitive and critical project of short duration (6 weeks max) that cross-cuts the business and has no clear manager, because it involves people from multiple departments. You can call it a "Code Red" or call it a Scrum or a "War Room" if you have a physical room for it.
Note that "Agile" comes from the consulting world. It suits well the needs of a small consulting firm, not yet very well-established, that lands one big-ticket project and needs to deliver it quickly, despite changing requirements and other potential bad behavior from the client. It works well when you have a relatively homogeneous talent level and a staff of generalists, which might also be true for an emerging web consultancy.
As a short-term methodology when a firm faces an existential risk or a game-changing opportunity, I'm not opposed to the "Code Red"/"crunch time"/Scrum practice of ignoring peoples' career goals and their individual talents. I have in mind that this "Code Red" state should exist for no more than 6 weeks per year in a well-run business. Even that's less than ideal: the ideal is zero. Frequent crises reflect poorly on management.
(Score: 2) by turgid on Thursday January 04 2018, @08:59PM (1 child)
You can't directly compare physical engineering with software engineering.
Agreed, but there's more too it than that. I've thought a lot about this over the years, and I have my very own Secret Plan for World Domination(TM) which I am working on. If it ever gets useful, I'll GPL it.
It's always been like that. Even when my father was a young man in about 1969 when he first wrote some engineering code on a mainframe.
You can open the bonnet of a car and look at the engine. You can't "see" software. You can't evaluate it just by looking at it. You have to read the source. You have to execute it in test harnesses. Everyone who reads the code will have a slightly different understanding of it. Good luck getting any PHBs to remotely comprehend any of it, and people who use Eclipse and Visual Studio.
Big software is developed in teams and it takes many months for a team to come together. Even then, everyone has their own pet ideas about how to do things. Ten years ago I landed on my feet, and it has set me up well. Too much to talk about here...
That does have its advantages, though. Monocultures are bad, in nature and engineering.
There is a book (for physical engineering) I must read some time. It's called Simplified Triz (? IIRC). Design Patterns are kind of like that for software but... I need to read it.
Indeed.
Sounds like attention to detail in modelling and specification... But still too manual.
I really must do some more work on my secret plan.
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 0) by Anonymous Coward on Friday January 05 2018, @01:20AM
Yes, this complicates things, but that also applies to microelectronics and (cellular) biology. Yet, we seem to know a lot more about those mechanisms than we know about the software we use in our programs. And that's odd, given that the software has been designed by ourselves, not by nature -- we shouldn't need to "discover" anything about it.
In order for software development to become proper engineering (in other words, to advance from astrology to astronomy), what we need is better tooling. And I don't mean that in the compiler/editor sense, but in the scientific sense: better language to unambiguously describe it, better metrics to evaluate it (not just performance, but reliability, robustness, completeness), better analysis to predict future behaviour (fuzzing and testing frameworks are a step in the right direction at least).
Yup, I didn't mean to imply monoculture here. I very much want a diverse software ecology, but one where interfacing with other components is as easy as just importing it into your build system -- the component specs should be extensive enough for your build system to automatically generate the correct bindings. Ah, one can dream...