Sorry, Moxie. Blaming Agile for software stagnation puts the wrong villain in the wrong play

Want a good time on stage, but you’re not a performance artist? Surprisingly easy. Fill a hall with an audience of your peers, tell them the world’s gone to hell in a handcart, then that they’re the only ones who can fix it. You’ll feel the love. Guaranteed. This is precisely what security superstar Moxie Marlinspike did in …

[John Hawkins]

This...

>>>

That this innovation isn’t happening isn’t because corporates are using Agile, it’s because the sort of innovation that’s big enough to be noticed is not the sort of innovation that a lot of tech corporates want.

<<<

I'm sure we've all noticed this at one point or another - lots of talk about innovation, but it's pretty scary and maybe not appropriate anyway for much of what is being done in any case. The most important thing is that stuff works.

Not that I've anything against innovation - great fun when you get a chance - but the word itself is becoming/has become part of the corporate BS vocabulary.

[Andy 73]

Re: This...

Agreed.

You can take it as read that Innovation Weekends and Hackathons are not there to innovate or risk disrupting an established business - they mainly function to allow devs to blow off steam and senior management to pretend that their main job is to NOT BREAK THE STUFF THAT WORKS.

It strikes me that Black Hat devs are encouraged to build the sort of hyper-focussed deep knowledge that encourages heroic acts of anti-social development: "Leave me alone, I gotta fix the Internet". That's the antithesis of incremental, collaborative and generally 'boring' construction that leads to both evolution and the occasional revolution.

Not that Agile automatically generates innovation - but when you're taking on a moderate to large project with a lot of uncertainty, it can be a reasonable tool for managing the process of development without the usual superstar antics.

[DJO]

Really?

Moreover, it’s easy to forget how unstable a lot of software was twenty years ago.

Seems to be going backwards as the big companies cut down on pre-release testing and let the users find the bugs.

Look at Visual Studio, VS6 (from 1998) was pretty basic but it was steady as a rock, VS2022 is ludicrously overcomplicated and as stable as an egg in a hurricane - regularly needs restarting when it loses bits for no reason like the toolbox randomly emptying itself or a form suddenly not showing any controls - not critical errors if you restart but a pain and symptomatic of sloppy or inadequate testing.

Also VS2022 has been out for a couple of years and few of these issues have been fixed, looking on line you find reports of the same problem and a reply from Microsoft saying they can't reproduce it (if they tried) and don't think it's worth doing anything.

[AndrueC]

Re: Really?

I've posted before that the state of VS was one of the biggest reasons for me choosing to retire (being asked to go back into the office for two days a week was another).

VS was unstable, pernickety and the development team wouldn't or couldn't fix it. It felt like they didn't care.

I enjoy the cut and thrust of problem solving programming issues - I even like bug fixing. What I don't like are having to reload my dev environment because Intellisense has got confused, the compiler can't find what it should or because the debugger has similarly got confused or just crapped out. At one time I even got a compilation error telling me that Object doesn't have a default constructor which is about as asinine and ludicrous as you can get.

[Irongut]

Re: Really?

My current VS2022 install likes to tell me it can't Clean the solution because there are files present. Yes, I know there are files present I want you to delete them you stupid piece of trash!

If I wait a few seconds and try again it will comply. Are the files it refused to delete suddenly not present? I have no idea. Have I tried reporting the problem to MS? Fuck no, why bother jumping through those hoops only to be told they can't reproduce it.

[AndrueC]

Re: Really?

It did seem to have a problem with file handling. Builds used to fail sometimes because VS claimed something had a file locked open. The file would typically be one of the DLL files it was supposed to be creating as part of the build. Or it could complain that the DLL it was supposed to be creating didn't exist.

[bombastic bob]

Re: Really?

Mate's "pluma" editor does 90% of what I need an IDE to do, and shell+make does almost all of the rest.

VS is overrated. I still use 2010 (the last of the NON-FLATSO aka NON-TIFKAM versions) if I have to do anything on winders. It just works. But 95% of what I do is Linux-based so there ya go.

[theOtherJT]

Re: Really?

We've also massively papered over how unstable a lot of things are. "Sure, this service crashes 3 times a day, but it's fine, it's a microservice. It's allowed to do that. We just restart it in the background and the rest of the stack carries on!"

You go digging into the system logs of a bunch of supposedly enterprise grade applications and bits of them are taking daily, if not hourly, dirt naps, only to be recovered by their management layer and all the client ever sees is that the application got really slow for a few seconds.

Now - one might argue that that is innovation - because we can now survive what would have been a full application crash a decade ago, but I disagree. The application should have crashed and then someone should have filed a bug report and whatever made it crash should have been fixed, but now that doesn't happen.

Systems that were designed for high resilience in massively distributed data centre type deployments - a case where it was supposed to be safeguarding against physical failures of network interconnects, or rack power outages, or other situations outside the applications control - are now being used inside what really ought to be monolithic programs as a way to cover up how shitty their code is. This leads to making the thing massively bigger, slower, and harder to debug than it ought to be. That's not innovation.

[tyrfing]

Re: Really?

VS6 was steady - unless you ran into a bug.

Then good luck getting a fix.

On the other hand, in the latest version they release fixes often, so it looks less stable.

But there's a lot more stuff in there (so more things to go wrong).

[Dan 55]

Google Maps

the arrival of Google Maps in 2005 stopped work in offices around the world as people clustered around monitors to look.

Nobody else remember Microsoft Terraserver in 2000? An example.

[Anonymous Coward]

Re: Google Maps

No because it was something only five people ever got to see. Google Maps was available to everyone, right there in the browser.

[Dan 55]

Re: Google Maps

Eh? So was Terraserver. It's in the video (and my memory).

[Pascal Monett]

Yeah, but nobody used Terraserver.

[Dan 55]

Yeah, all the cool kids used StreetMap.co.uk which is still amazingly online and still looks about the same.

[JoeCool]

In North America the Pioneer was Mapquest.

and they were swept away by maps.google

[Gene Cash]

Re: Google Maps

Well, sure you could use Terraserver.... if you were willing to wait the 10 minutes for it to render a map, and another 10 minutes because you scrolled 5 pixels.

Google Maps actually used to work, and you could quickly scroll around in it.

[Anonymous Coward]

Re: Google Maps

> Nobody else remember Microsoft Terraserver in 2000? An example.

The innovation brought about by Google Maps was the so-called slippy map UI paradigm.

Man + dog (+ myself) were doing "click on a corner to pan and have the map redraw from the server" since the mid-90s, mostly using MapServer, an early open source web mapping system (still around, btw).

Not having to pay for global satellite imagery was another major step. Before Google Maps we used to have to buy the imagery and/ or collect mapping data ourselves. After Google Maps you would just augment their data with your own via the JavaScript APIs. It was also, along with GMail, what got JavaScript and HTML moving again after years of Microsoft sponsored stagnation (Microsoft thought, incorrectly as is evident, that if computing moved away from the desktop they would be toast. Their business model at the time did of course become obsolete, but with the arrival of a new generation of managers they figured a way to move on and keep making money).

[Anonymous Coward]

Mr Benham not taking down the video?

As he did a couple of years ago when his CCC talk was, let's say, less than enthusiastically received?

[Howard Sway]

remaps their functions to something that dehumanizes the experience

I think you really meant to say "humanizes the experience". At least I hope you did, because it feels like the magic wand that does what you said was invented quite some time ago.

The desire for magic wands is of course best left in the world of books about wizards for children, because fantasising about software that can magically adapt to a diverse and continually changing world of online walled gardens, set up to keep profits fenced off from any competition, is to hope for something that's never going to happen without the megacorporations being broken up into small enough pieces that they would need to buy into the idea of openly sharing of information to survive.

[Binraider]

Set out the scope of your problem, define what you want to get out a thing; and then build it. How you build it does not change the scope.

A lack of innovation suggests that A) most problems worth solving are already solved and B) that most people are crap as scoping problems therefore run into problems down the line.

[Doctor Syntax]

Or C) there's a problem but nobody cares enough to solve it.

[michaelaubert]

there's a problem but...

no rich people care enough to solve it.

;-)

[may_i]

He didn't really say it was Agile's fault

What he actually placed most of the blame on is the layers and layers of black box abstractions so beloved of Microsoft and there, I completely agree with him.

When all the software developer sees of his tools is some horribly abstracted black box package, that's as far as they get in understanding what they are working with. They lose sight of how the stuff hidden by the abstraction works. This is behind the fact that our computers are vastly more powerful than they were 20 years ago but don't deliver any of that improved performance to the end user.

Many developers make fatal, performance guzzling mistakes, by restricting their level of understanding to the highest possible abstraction and have no idea why they suddenly find their latest and greatest program exhibiting the performance level of a drunk snail when it gets real production data thrown at it. Add to this, the fact that Microsoft deprecate C# packages and abstractions at an ever increasing rate, making keeping code up to date almost impossible and you have the recipe for the malaise that Marlinspike was actually referring to.

[Charlie Clark]

Re: He didn't really say it was Agile's fault

Yes, his real gripe was the use of "frameworks" and "stacks" to throw something together quickly with few of those involved really able to understand the potential security implications. Web frameworks together various database libraries were probably the start of this because, suddenly you could develop something that interacted in the browser with live data and thus the MVP – mininum viable product – so beloved of VCs was born. This was an even more effective way of opening wallets than a topnotch Powerpoint presentation. Agile unwittingly fed into this because many of the frameworks were able to point to their track record of development and maintenance using various different "agile" approaches. So customers could be promised fast and reliable incremental development until things hit the wall – or maybe it was a whale when Twitter for one suddenly stopped working because the framework hit its limits. VCs still didn't care because their dual mantra of moving into unregulated areas and then relying on network effects to make competition impossible would mean customers would have no choice but to keep on paying – and we're seeing this increasingly in SaaS environments. And it spread from there: software development was relegated to choosing the right (open source and therefore free) frameworks. If things didn't work we were told that agile, and some mythical man months, would solve the problems. And this has, by and large, been extraordinarily successful.

But the disregard for the discipline of software engineering and potential security risks has created potentially huge attack surfaces that no one involved can understand, and that none of the proposed methodologies can solve; though throwing some mythical man months at them remains a perennial favourite!

As someone who both uses and has contributed to various frameworks I can see both sides: you do stuff you would never have been able to do on your own, but you will probably never understand the whole system. I'm not a computer scientist, so I'm hopeless about the lower level stuff, but I'm also aghast at things like the reluctance of many developers are afraid to work directly with the database, trusting to their abstraction. But, if you're running a public-facing system, not knowing or even asking about isolation levels, permissions, etc. or even views, is asking for trouble. And I'm sure there are many examples in other domains. Deskilling tasks through automation has been the clear aim for several generations now because it means you can replace well-trained and expensive employees with cheaper ones off the street or in another part of the world, and the tail risks are considered negligible.

A piece that focussed more specifically on the potential side effects of this complexity – and watching someone forensically pull your world apart is a real eye-opener – would have been welcome but probably wouldn't have got as much publicity.

[may_i]

Re: He didn't really say it was Agile's fault

Indeed. Handling database concurrency in a sensible, predictable and reliable way cannot necessarily be accomplished with the "one size fits all" thinking behind most abstractions. Few developers have to make this work by talking directly to the database and few of them have any concept of how isolation and locking strategies affect concurrency.

As long as you don't have thousands of concurrent updates to your database, the abstraction works. As soon as you get into real sized workloads and it all falls apart, unless you understand the database, you won't even have a clue how to handle the volume.

As I'm an old bastard, I can work in everything from assembler to C#. This is what leads me to agree wholeheartedly with Marlinspike's point about the dangers of not understanding programming any further than the rosy view of reality presented by many high level abstractions.

[Daren Nestor]

Re: He didn't really say it was Agile's fault

My old man complaint was when my university switched from teaching basic programming in C, then C++, then Java to starting and continuing in Java with a sidenote in C. Java is too abstract to be a good teaching language for computer science - if you don't trip over a null pointer once or twice, if you don't have to explicitly allocate/de-allocate memory, it's harder to appreciate the resource management required. The GC just makes all that go away but when teaching how to code I genuinely believe that resource management is as important as control flow to learn. Memory, disk, and CPU resource management can and should be taught, and of those memory is the one that you're interacting with the most in basic programming.

[Anonymous Coward]

Re: He didn't really say it was Agile's fault

> Java is too abstract to be a good teaching language for computer science

If you're not teaching in Lisp, you're not teaching.

And if you're being taught in Lisp, the first thing you learn is that computer science is neither a science nor about computers.

Nobody calls carpentry "Hammer Science".

[Andy Mac]

Re: He didn't really say it was Agile's fault

The first thing you learn with LISP is that sociopathy is a real thing.

[Michael Wojcik]

Re: He didn't really say it was Agile's fault

My undergrad degree used Pascal, (VAX) assembler (also some 68030 in the compiler-design course), Fortran, LISP, Scheme, ML, C, Modula-2, and possibly some other languages I've forgotten. And it involved co-op work, where I used a bunch of others.

If you're not learning multiple, significantly different programming languages, you're not getting sufficient breadth in programming.

Programming, of course, is neither computer science nor software development.

[Michael Wojcik]

Re: He didn't really say it was Agile's fault

you will probably never understand the whole system

No one — not one single person in the entire world — understands "the whole system" for a non-trivial software application. Marlinspike is strawmanning to an absurd extent.

And software development has depended on levels of abstraction since we invented assemblers.

The supposed problem that Moxie supposedly identified is simply that most developers don't want to learn and don't want to think. That has nothing to do with Agile, frameworks, abstraction, or any of the other bugbears he and others are trotting out. It's straight-up bullshit.

There is nothing that prevents someone developing, say, a web-front-ended business application from having a passing understanding of not only whatever Javascript flavor-of-the-month framework is being used, but HTTP, TCP/IP, the host OS(es), transactionality, database normal form, race conditions among cooperating simultaneous processes, locking models, the CAP and FPL theorems, business requirements, the latencies associated with various types of resources, CPU versus I/O versus interaction-bound tasks, and so on. That's just a matter of paying some goddamned attention and doing a little intellectual work.

But it is impossible to have deep knowledge of every layer, even if you read at superhuman speeds and retain everything you learn; there are too many levels, too many varieties at each level, and all of it changes too quickly.

So the problem is not the one Marlinspike claims, and neither is the solution.

[ntt]

It's not Agile, it's the black boxes

What I do agree with Moxie is that in modern corporate environments developers work in compartments (black boxes), and the companies they work for are organized in compartments too

No one in those cages has a F idea as to what the company wants to achieve, they only see a tiny part of it, and the company actually discourages people "wasting time" with thinking beyond their duties...

No wonder about the current hype to replace people with AI's, robots or whatever else at the earliest opportunity

[Dan 55]

Re: It's not Agile, it's the black boxes

Yes, Agile works very well with corporate silos to keep people in their box.

Stay in your box, do not stray outside your box, don't waste time looking at something which is not assigned to you. Just take your next ticket off the top of the Jira pile and fix it, you don't need to understand anything about the wider system.

[boblongii]

Re: It's not Agile, it's the black boxes

Yeah, Agile introduced that sort of thinking. I'm not sure exactly wen but it must have been sometime around 1760 before Smith stumbled across the pin factory he wrote about in Wealth of Nations.

[Michael Wojcik]

Re: It's not Agile, it's the black boxes

Indeed. Moxie's argument, and those of commentators who agree with him, is basically "here's a thing I don't like; it must be responsible for everything bad!".

[Electronics'R'Us]

I sort of agree with some of his points

And disagree with others.

In the original article, he railed against the use of frameworks [1].

I don't oppose frameworks in general but I do think they are overused or used when it is really not appropriate to do so. Do we really need an enormous framework such as electron for simple applications? Honest question.

When he was going on about understanding the underlying hardware (knowing what the computer is actually doing) I disagree. COBOL programmers didn't really need to understand what the underlying hardware was doing but when I am bringing up a single board computer, it is imperative that I thoroughly understand precisely what is actually going on.

Try initialising DDRx without understanding all the register settings (there are a lot) or initialising the DMA subsystem. That way lies not only madness but also a major loss of hair and perhaps the consumption of large quantities of 'refreshments'.

It is courses for horses, really. Not everyone writing code needs to understand the internal details of the parts we are using as it would have no measurable gain [2]. For those who do need too know, it is interesting that fully understanding a modern microcontroller from a family we have never used before can take several days or weeks depending on the architecture. There is typically 4000 to 5000 pages of documentation in total for a modern microcontroller.

1. The standard C library can be viewed as a framework (as can numerous others); they all provide an abstraction layer to a greater or lesser degree. Obviously C exposes far more of the hardware level than python libraries for example.

2. That does not mean I would not encourage them to look into what the machine is really doing, just that for many tasks it is unnecessary.

[doublelayer]

Re: I sort of agree with some of his points

"Do we really need an enormous framework such as electron for simple applications? Honest question."

No, but I can see why people use it. Building cross-platform applications is annoying. I don't really want to spend a lot of time working on UIs, and what I'd like even less is designing UIs at least three times for different operating systems, then tying each one to the backend. Chances are that, if I try, I'm going to get annoyed and stop before all the GUIs are done, or they're going to get out of sync. That has been a problem for a while and lots of frameworks for cross-platform GUI development exist.

A lot of them have some quirks, such as not looking quite right or interacting with the system in expected ways. For example, Java's standard GUI libraries have a tendency to react oddly to keyboard commands, mostly not reacting at all when they're supposed to. That's not good. I was also looking at some software that used GTK which came with an announcement in the documentation that this would possibly work with screen reader software for the blind on Linux, but wouldn't work with it under Windows. From the sound of their warning, it sounds like a lot of users don't understand how hard that is to fix and the authors don't know how frustrating that must be for a user to hear. When considering what framework to use, you have lots of little problems like that.

Using HTML seems like a realistic option. After all, every OS can render HTML. While I don't use Electron, mostly because it uses too much JavaScript and system resources for my liking, I have often built small GUI applications by spawning a local HTTP server and opening a page rather than using something else. They're lighter on resources and I don't usually stay with that method at the end, but when I'm trying to create a UI I can rely on to work well without spending too much time on it, it's one approach that I've used. While we have problems that are that annoying, frameworks to fix it will continue to proliferate and developers who want to get something working will choose them.

[Pete Sdev]

Re: I sort of agree with some of his points

Do we really need an enormous framework such as electron for simple applications? Honest question.

If you have a user GUI application that you wish to be available to largest possible audience (usually a good thing) and you lack the resources to produce builds for every OS (building, testing, etc ) then it's possibly a reasonable choice.

The framework is large because its saving a lot of work elsewhere (rule of conservation).

User Oses are a lot more diverse than 20 years ago. While I'm not a particular fan of Electron,I have no desire to return to the bad old days of "available for Windows" only.

[tatatata]

Once again, an Agile apologist reacts to an observation about the bad side of agile. And guess what: it is not Agile's fault. Here the observation is how Agile kills innovation. Of course it does. Every engineering methodology kills, or at least maims innovation.Waterfall did, extreme programming did, and Agile too. Innovation IS locked in the frozen meat store of Agile. No engineering method is a substitute for thinking.

Ofcourse, there is the car-analogy, because everybody accepts that programming is the same as making or driving cars. "Devops can be a car crash, but car crashes are rarely the fault of the car."

The problem is "None of that will help if you’re still trying to fix old problems in the old ways. That’s been done." And Agile, dating from 2001 has become an old way of doing things.

And yes, if people understand and can work on a full stack, like security engineers that have been exempt from scrum and agile, that would help. It would make large projects harder though.

[JoeCool]

Apologizie - for What ?

Agile is an implementation technique. It does not attempt to replace "thinking", much less do anything hindering "innovation.

[Michael Wojcik]

Once again, someone with an axe to grind grinds the axe, without making an actual argument.

[Pascal Monett]

"car crashes are rarely the fault of the car"

That's evolving !

[HuBo]

The Martyr Principle

I'm with whomever requires the stiffest of S&M rigor in this here torture that is contemporary software development. Like the good folks at Stanford's CS 190: Software Design Studio, and their 2015 lectures on Managing Complexity. They steadfastly whipped thus:

* "Module writers should embrace suffering: Take more pain for yourself, so that others have less"

* "Let a few module developers suffer, rather than thousands of users"

* "Minimize "voodoo constants"" and zombie parameters, with unknowable right values

Advice to live by for sure ... turned me right hairless and caerulean!

[Doctor Syntax]

Maybe what drives product design these days is marketing and for marketing putting a new skin on things counts as innovation.

[ecofeco]

And don't forget more clicking! If we add more clicking, it's innovative!

[TReko]

Don't forget taking away features, too.

Even small things like Windows 10 makes it very hard to set up arbitrary UI colors.

The amount of PR spin involved in MS allowing Notepad to have a dark mode is incredible. Next year it will even support tabbed Windows.

I get the feeling software is now designed by multiple layers of committees.

[JRStern]

Devops this

>Devops can be a car crash, but car crashes are rarely the fault of the car.

And this is the good news?

Yes, Devops kind of travels with Agile, but it's worse, if anything, OMG.

Fine for tiny things, horrible for big systems.

Devops is good if that's where you put the one person in the building who *does* know stuff down to the fundamentals, but that's just Atlas holding up the whole world on his shoulders, it doesn't scale.

[Tron]

Where are the distributed services?

Meta managed one, but there are so many other options, not least adding a social media UI to an e-mail client - E2E encrypted social media operating user to user, without a central hub.

Most of the changes in the last 20 years have been for the worse. Switching from installing an .exe to subscribing to a service. Hideous, unless you want the net to function as a surveillance network for governments and an ATM for GAFA, all at the expense of users.

We need stableware - particularly a new OS that is stable for 20 years. Not updating more often than Premiership teams change their manager - updates that can break more than they fix. Maybe then governments wouldn't have to hand over billions of our cash every few years for updates. It could be Pi based. Write the code well, sandbox everything, proper encryption options, and you wouldn't have to keep patching it. Data flows like water, software is merely a set of plumbing tools. What we do with computers has never really changed much since the 80s.

Most changes in the last two decades have been little more than gratuitous acts of look and feel, breaking compatibility. There is nothing out there that you couldn't have done on Windows 7, 15 years ago.

And we could use a return to Google Search 2004, because the current version excludes more than it has ever done. It is more like a global censor than a search engine. And not just search. How many options have vanished from the software you use.

There are lots of innovation options out there, at the browser level, with simpler tech, sharing platforms and ad hoc networks. I expect corporate/government restrictions, abuse of patents, lack of interest in the VC community, and industry gatekeeping to play a major role in preventing them from getting any support.

[doublelayer]

Re: Where are the distributed services?

"adding a social media UI to an e-mail client - E2E encrypted social media operating user to user, without a central hub."

Most social media requires a central hub at some level, not working with user-to-user. I can't see what everyone here has written if every comment has to come from its user's computer. It wouldn't be on, or I wouldn't be known to it, and therefore I couldn't read it. Even finding the servers to ask for their messages would be a problem. The closest you can get is Mastodon, and there are still lots of central hubs involved. Not everything can work individual-to-individual.

"We need stableware - particularly a new OS that is stable for 20 years. Not updating more often than Premiership teams change their manager - updates that can break more than they fix."

The goal to just right code well once and basically never change it is not new, and it's no more realistic now than it ever has been. Things change more often than that or bugs get found, whether they have security vulnerabilities or just cause the program to do wrong things. It's true of everything we have and will be more or less true for everything that's similarly capable. To avoid it, you need to give up lots of functionality.

There are open source programs that do a lot of what you'd like to do, and it's not "corporate/government restrictions, abuse of patents, lack of interest in the VC community, and industry gatekeeping" that are keeping them from taking over. In many cases, it's users not wanting to do the extra effort that comes with self-hosting something and, to some extent, lack of the funding necessary to advance them quickly as competitors can. As The Register noted, there are barriers to open projects in users' desires and the software's design that have nothing to do with big tech abuses (there are many, but they're not always to blame) or government restrictions (they talk about banning encryption a lot, but they haven't actually done it).

[jpennycook]

Re: Where are the distributed services?

> not least adding a social media UI to an e-mail client - E2E encrypted social media operating user to user, without a central hub.

You'll likely get some Government interest in that, given that it would be of interest to organised crime etc. It was done ages ago anyway - encrypted P2P platforms don't seem fashionable any more (or at least I don't hear about them, but maybe that's because I'm getting old).

[ecofeco]

Innovation is still happening

It's just not happening at Giant Behemoth, Inc., et al.

Good software is constantly being created, then bought by GB, Inc, and then extinguished. I'm not talking about just M$ either. It happens at every giant corp.

[gweedo]

The problem isn't the methodology (waterfall, agile, etc.), it boils down to not understanding the problem you are trying to solve and then trying to design/build/operate it with inexperienced teams.

[Plest]

From my persepctive I wouldn't say it's s much stagated as simply become so focused on the miniutae of developement that no can see above the cell walls they're working in. You're simply given the job of writing a microservice that process X into Y and that's all you need to know and so that's what you do. What happens next is none of your concern.

It's almost as if we're now like the machie operators of the industrial revolution, this is your station and you simply put raw material in there and make sure ABC comes out there, if it breaks report it and someone will come and fix it for you. Now get going as you'll be there 14 hours a day, 6 days a week!

[Pete Sdev]

There's more software being written than previously. So the ratio between amount of software produced and the number of people competent to write it has worsened.

One of my favourite bugbears: web "developers" that don't appear to know the difference between a signed and unsigned integer, and have apparently never heard of foreign key constraints. Even though relational database theory is from 1973 and thus older than they are. One of my colleagues, with years of working experience, was recently astounded when I introduced him to SQL's ENUM type...

Personally I'm in favour of a licence scheme for programmers, similar to that for doctors, architects, etc.

I believe methodology has improved- there's more of a problem that many places still run on reality-denying waterfall methods. I scream internally everytime a project mangler proudly displays their gant chart.

Things like unit testing and automatic builds have progressed in the last couple of decades too.

[Anonymous Coward]

Ah, but Agile IS a large part of the problem. Focus on your part, forget the big picture. Constant changes -- isn't that what "Agile" means, after all? Daily "scrum" meetings. "Huddles" to discuss problems. Retro meetings to discuss what you did. Other meetings to discuss what you're going to do. Meetings to discuss why we have so many meetings. Scrum-of-scrum meetings to discuss why there are so many meetings discussing the number of meetings. Endless dissection of how many minutes it took to accomplish this task vs. how many minutes we think it will take to accomplish that task.

It's a wonder that anyone gets anything done in an Agile environment. Come to think of it... does anyone get anything done?

[TimMaher]

Re: does anything get done?

Can we book a meeting to discuss that?

My diary is in my coat pocket.

[Stoic Skeptic]

The root of the problem (as I see it) is that software development is no longer the domain of software developers and now controlled by corporate managers with no background in software development. They grasp for metrics that they can relate to and software greatness is not one of those things they can measure to put on a weekly/monthly report to upper management; you get what you measure.

The analogy of this is the result of Boeing making an accountant the CEO rather than an engineer.

[Rmack350]

I think we're talking about a distinction between strategy and tactics. Agile is a tactic. What i see at my workplace is a lot of energy being put into managing an agile process. I don't see the overall strategic goal, but then again i probably wouldn't.

I big problem with the agile workflow at my workplace is that its totally reactive to sales whims that change faster than the agile cadence. Again no visible strategy. The other thing i see is a lot of rookie software mistakes that might have been avoided with more time and supervision. There seem to be a lot of inexperienced coders in the world trying to get work done and checked off rather than done well.