13 ms·
Agile Is Dead, Long Live Continuous Delivery
- usloth 10y agoIf Agile is dead, why is there a new article about Agile on HN everyday. I think Agile is dying, not dead.
- striking 10y agoIn that case, Agile has been dying for a long time now.
- ludamad 10y agoThis article seems to just be stating that the term is misused now. It's not dying/dead so much as becoming a less than useful term
- goalieca 10y agoBecause we all wish agile was dying?
- stcredzero 10y agoA better analogy, is that some of the more advanced examples have "sublimed" as in Iain M. Bank's "Culture" series. I was just having this thought last night. "eXtreme Programming" and Scrum seem to either exist in a clunky bureaucratic mutant form or have evolved into companies that use CI and prioritize really good communication. (Yes, people in the late 90's and early 00's did sometimes write it like that.)
- enjo 10y agoI see no indication that agile is dying. The consultant speak cult that developed around it is. The hugely processed SCRUM version of it seems to be. Yet the fundamental idea behind Agile (in the manifesto) seems to be as relevant as ever: >Individuals and interactions over processes and tools >Working software over comprehensive documentation >Customer collaboration over contract negotiation >Responding to change over following a plan The process we've designed and use daily at Gridium most definitely adheres to those principles. We've tested and abandoned the idea of "sprints" and weekly estimation cycles. We have no idea what our "velocity" is. Yet we collaborate with customers nearly constantly. We are highly responsive to changes in the business. We integrate continuously. We deploy very often. All ideas that I think where present when we all fell in love with the idea of "agile". * Edit: Shame on me for not reading the article, because I basically summarized it :) Heap your downvotes on me HN!
- maxxxxx 10y agoYep. If people checked their actions against the agile manifesto they would immediately see that most scrum teams violate "Individuals and interactions over processes and tools" and "Responding to change over following a plan". A lot of scrum teams I see are fully process and tool oriented and have no ability to respond to change. I hate when I hear "Yes you are right but we can't make changes because the sprint would not finish". I also have given up on fixed sprints for my (not anymore) scrum team. We have a prioritized backlog and whatever is next gets done. More like Kanban. As long as people behave like adults and do their work efficiently it works pretty well. We still have a weekly velocity and that number is surprisingly reliable.
- tamana 10y ago>Yes you are right but we can't make changes because the sprint would not finish". That makes absolutely no sense because the sprint always finishes, on a scale far basis. The only way to make a sprint not finish is to submit code that cannot be safely deployed, and that is a bug in the code, nothing to do with changes in plan.
- geebee 10y agoThe daily standup ("scrum") did make some sense in the context of agile development. The idea is that you embrace the unpredictability of software and respond to change. So you take on a task, but you accept that the task is likely to not go as you expected. You may need to change direction. You may need to take a different approach. Or you may need 10 weeks instead of 1, and even that is getting fuzzy… under these circumstances, it can be useful to remain in frequent contact with the development team and business/end users users. But as you pointed out, daily scrums can essentially devolve into what is essentially a policing of developers to make sure they are staying the course and are reminded daily of their deadlines. It's actually just an unusually unfriendly version of waterfall. Why? Cause at least in waterfall, the business users are forced into something unfair and impossible as well. It's impossible for developers to accurately estimate completion dates, but it's also impossible for business units to accurately and fully spec out a software application. "You didn't meet your estimate"... "Yeah, well, you changed your mind". It's a nasty business, but there you go. Best to avoid the entire thing and work on projects that are very high value but aren't deadline dependent, where the value of a developer is measured by working software at reasonable intervals rather than daily discussions of sprints, stories, and deadlines. Actually, in some ways, that sounds more like what agile is supposed to be than all this scrum/velocity/stories stuff that isn't in the manifesto in the first place.
- TheOtherHobbes 10y agoIt's a zombie. It eats brains and can't be killed.
- tempodox 10y agoI wouldn't mind if it died a little less loudly.
- ktRolster 10y agoHas anyone ever worked on an 'agile' team that wasn't based around scrum or XP? I'd be interested in hearing your experiences.
- nessus42 10y agoYes, we use Kanban where I work. We've been doing "continuous delivery" and "DevOps" for years. It's not bad, but I still don't really like scrums.
- monknomo 10y agoI work on a non-dogmatic agile team. It works pretty well, but only because we have engaged, technically sophisticated stakeholders. We have a process, but the personal relationships and collaboration are really the meat of it. I think our process (which is fairly informal) would fall apart if different people tried it.
- joshuacc 10y agoYes, I have worked on agile Kanban teams. The experience was more or less the following... 1. What's the next task/bug/story we should be working on? 2. Build & test it. 3. Ship it. 4. Rinse & repeat. We'd have meetings periodically to define new sets of tasks and figure out priorities, and/or to reflect on things that hadn't gone well. But these weren't necessarily scheduled on a regular basis. We did them as needed.
- jheriko 10y agobuzzword filled click-bait. :/ just use your brain. agile is only a problem when people follow it religiously instead of intelligently imo. its just one tool in the box, not the ultimate methodology.
- aivosha 10y ago100% agree
- smoyer 10y agoI totally agree ... Don't waste your time reading this article. And if you ever have the opportunity to write an article yourself, remember one simple thing - if you're going to write several hundred words of content, you should try to tell your target audience something they don't know!
- scolfax 10y agoAgreed. But feel compelled to add: Agile is only a problem when teams pretend to follow it but actually don't.
- jheriko 10y agoI'd prefer to say "misinterpret" than pretend to follow... but even so, following it as presented to its totality is still going to be sub-par. Some of the points in the Agile manifesto are just arrogant, unjustified statements of fact or vague and useless comments. Some people hate face-to-face interaction... and what the hell is a 'regular interval'... and sometimes a clear vision and direction from above achieves the very greatest of results that the team without it would have failed to produce. Its not useless, but its not without fault either.
- p4wnc6 10y agoWhen everyone misuses a tool, it's the tool's fault. And everybody misuses Agile.
- jheriko 10y ago
- deleted 10y ago[deleted]
- xirdstl 10y agoOut with the old buzzwords, in with the new.
- rbanffy 10y agoWhile their meaning remains constant.
- jonnathanson 10y ago"Meet the new boss, same as the old boss." -- The Who
- jcrites 10y agoThe author mentions the Agile Manifesto. It's worth a read, and the concepts it focuses on are somewhat different than the impression that you'd get by reading about Agile in popular blog posts or websites: http://agilemanifesto.org/ http://agilemanifesto.org/ Manifesto for Agile Software Development We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. That's the gist of it: being Agile means valuing the things on the left more. It is a set of values, not a methodology. I think this manifesto is wise. Like Zen koans, contemplating and discussing it provides an understanding about what Agile is. Fortunately it's not cryptic, although the meaning behind the statements might become clearer with consideration and experience. "Individuals and interactions" is saying, focus on getting people together and talking and working things out, not following a predefined process or using complex tracking tools. "Customer collaboration over contract negotiation" is written, I assume, in the context of contract work, but it applies generally to the relationship between the software team and stakeholders: collaborate with your stakeholder directly, rather than trying to negotiate some kind of specification (contract) up front. The Twelve Principles of Agile Software are also worth a read: http://agilemanifesto.org/principles.html http://agilemanifesto.org/principles.html These principles are what Agile is about -- not some particular methodology. Indeed, blindly following a methodology like Scrum would violate the Agile Manifesto ("individuals and interactions over process"). One of the things that I like about the Agile Manifesto and Principles is that they're not prescribing a particular method; they are instead providing some principles to consider while thinking about a situation. I've always liked Amazon's Leadership Principles for the same reason: https://www.amazon.jobs/principles https://www.amazon.jobs/principles - insight comes from thinking about what it means to embody a principle in a given situation; or what it means to value one principle over another, in what situations, and why. It's not prescriptive nor a method, but it's a starting point for discussion, and a way of talking about what we value as individuals, a team, or a company.
- danmaz74 10y ago> "Customer collaboration over contract negotiation" is written, I assume, in the context of contract work This should be about contracts between software development firms and their customers, where the development firm gives a quote to complete a project based on very detailed and legally binding specifications - which is a big problem because you can't know every detail before the project even starts. Hence a big part of the "Agile" philosophy.
- tomc1985 10y agoNot sure if I agree with his post, but to hell with the gurus! It's a mentality we need to move away from, and it is nauseating the way people drool over so-called 'gurus'. Software is not religion... it's just software
- coldtea 10y agoUnfortunately it sells, and idiotic managers love it because it gives them a ready-made recipe, instead of having them come up with something that works for their product and their team.
- rbanffy 10y agoI see it more as death by ubiquity. When the last laptop is sold, we'll proclaim the computer is dead, but we'll do so from our phones, tablets, headsets and whatever we use to tap into vast AI's that help us navigate the unfathomable complexity and depth of an ocean of information. We will proclaim agile is dead without realising we constantly adapt our code to changing needs of our users and their representatives who are very deeply involved in the whole process and who give us feedback as we constantly release new functionality.
- jldugger 10y agoIt's funny. Our devops team is in the midsts of a long migration from cfengine to Chef, and I recently started managing the project more like agile, with sprints and task planning meetings and so on. Sure, for our clients and internal developers, devops makes CI happen. But as far as the devops themselves are concerned, Agile hasn't gone anywhere.
- andrew_wc_brown 10y agoX is Dead! Long Live Y! Until Replaced by Z.
- hyperpape 10y ago"We are now more squarely in the age of Microservices, Mobile first, Polyglot, post-Java JVM languages, GitHub, Docker and the emergence of a world being eaten by Software." sigh I can see how Docker is relevant, Microservices are arguably relevant, maybe even GitHub, but that still leaves 4 out of 7 items that have nothing to do with continuous delivery.
- lostcolony 10y agoI like how he tries to supplant agile with something that doesn't even attempt to solve the same problems that agile (like waterfall before it) attempts to solve. Both agile and waterfall methods attempt to give you a pattern by which you can predict when software will be delivered. That's the main business value. The suits don't care how the devs operate, provided they can get things on time. Waterfall tried to do this by trying to understand the problem as fully as possible, to liken it as much to previously solved problems, and to involve gurus to say "that kind of problem will take X amount of time to resolve", and thereby create milestones and delivery dates. Agile instead said "look, we don't know enough at the start of a project to do that. Let's instead keep track of everything we want to do. Let's try and estimate each set of tasks (stories), individually. And then let's rank them in priority. We can measure how good our estimates are, we can modify them, we can generate more data and determine what we'll have at a milestone, and then can either push back the due date, or at least recognize that we won't be able to ship the entire feature set at that time. Continuous delivery can be done with either one of those (it almost never is in waterfall, but it -could- be). But by itself it offers a business nothing for planning purposes. All it does is allow an immediacy, a "as soon as it's done it's out in front of the users". This may or may not be a good thing to the business, but it doesn't solve the basic issue that business people want to know when they can expect a given set of features to be live.
- voodootrucker 10y agoThe trouble is that in dynamic environments, the discipline necessary to properly practice scrum isn't really possible. It takes longer to define the requirements than it does to code, and once coded they change mid-sprint. The trouble with waterfall is that it tries to predict beyond the scope of a sprint, which just isn't valid. Project estimates are asymmetrical curves (likely poisson?) and you can't add them up and expect them to cancel out: http://www.sketchdeck.com/blog/why-people-are-bad-at-estimating-timelines/ http://www.sketchdeck.com/blog/why-people-are-bad-at-estimat... The problem is like recursive state estimation, except when you break it down just to estimate and add it back up you aren't actually taking any new measurements. On most projects it's usually just better to estimate based on relative size to your last project, start delivering continuously, and do a forecast of completion (as opposed to an estimate): http://www.agildata.com/keep-it-lean-you-arent-ready-for-scrum/ http://www.agildata.com/keep-it-lean-you-arent-ready-for-scr... (edit: spelling)
- strictfp 10y agoContinious delivery is Agile. In fact, regular deliveries are by many considered the single most important indicator of a working Agile process.
- kensign 10y agoExactly, every 2 weeks, sometimes less, we consistently release what has been accomplished in a sprint. This "blogger" is talking out of his ass. Like always, declarations like this stir the anti-agile rage pot. It's getting more and more laughable as the years go on.
- xirdstl 10y agoThis blog post is just an advertisement for the Gradle Summit.
- vorg 10y agoIf you click on (gradle.org) at the end of the title above, you'll see a long list of pages submitted to Hacker News from that website.
- deleted 10y ago[deleted]
- qaq 10y agoWe could create a template for such articles {Buzzword} is dead because {random text {sprinkle buzzwords}} {Plug some commercial thing}
- qaq 10y agoWhich summarizes half the biz model HubSpot is advocating :)
- mml 10y agoAgile is like <pick your religion>. Widely professed, rarely practiced.
- ralmidani 10y agoI can't wait to hear someone declare "programming methodologies are dead. Long live programming."
- ktRolster 10y agoThis might match: http://programming-motherfucker.com/ http://programming-motherfucker.com/
- hoodoof 10y agoSounds like he is heralding a new age when people just go to work and.... do programming. http://programming-motherfucker.com/ http://programming-motherfucker.com/ Customer: errr.. what methodology are you following? Developer: none of that agile garbage I can tell you...toxic stuff. I am programming.
- are_hem 10y agoi don't judge, but I would love to see you raise some money to build a real business without someone who needs that "methodology". keep on keeping up - code without purpose is just masturbation
- joesmo 10y agoWaterfall is still the right choice for many products. The fact that the author can't even acknowledge that shows how little he understands about software development. The whole article is mainly a bunch of garbage from one narrow minded point of view with an obnoxious title.
- coldtea 10y ago"Continuous Delivery", huh? Yeah, let's replace one consulting fad (the 4 or 5th I've seen in my career, I entered when "Waterfall" was still in vogue, then XP, then Agile, some variations of each too) with another. How about this methodology: http://programming-motherfucker.com/ http://programming-motherfucker.com/
- chrisseaton 10y agoPeople tell me that waterfall was never really a thing, and it was only ever a name for how things should not be done and that nobody ever actually advocated it. Is this not true? I'm too young to remember what came before agile.
- BurningFrog 10y agoOnly opponents to it calls it Waterfall, but I've definitely worked in environments like that back in the old days. We got very little done.
- andrewbinstock 10y agoPure waterfall as it's depicted by Agile consultants was never a thing. Think about it, how could you possibly code an entire app and only then debug it? However, there was a waterfall-like process that was widely used. After getting the reqs and design in place, you started coding and you mostly coded. You would compile as you went along and made sure that your code worked on the handful of tests you put together as you went along. When the app was mostly coded, you then started more serious testing: writing more elaborate tests and verifying functionality. This step often highlighted buried errors that you then spent time debugging, writing additional tests, and so on. So, the biggest innovation in Agile was the latter's orientation towards developer testing concurrently with coding. Which, of course, has had many other ramifications. While the old way of doing things might sound klunky by today's standards, when done right it actually worked better than its reputation. Because devs hated spending hours in the debugger, they tended to code very carefully. The concept of "let's code this and run it through some tests to validate it" was unknown. Rather you coded so that you were pretty much sure that what you were writing worked properly if it compiled without error.
- deleted 10y ago[deleted]
- ebbv 10y agoSo to summarize this article: - Agile is Dead because people abused it, so we should move on from the term. - Instead use the term Continuous Delivery. By the way this term doesn't mean anything, use whatever system you want. - Lots of buzzwords.
- meganvito 10y agoI think what features this article is exactly what we see the one facet of agileness of its practitioner. The distortion of science and engineering methodology and practice. Before you do a big thing, you have to prove a bunch of small things work as the foundation. Any increment will not be linearly scalable. Finally, what you claim should be strengthened by your data, charts, plots that are verifiable by others.
- dronacharya 10y agoHere's a quote from the first paragraph of this page: http://agilemanifesto.org/principles.html http://agilemanifesto.org/principles.html "Our highest priority is to satisfy the customer through early and continuous delivery of valuable software." (Emphasis mine) Continuous delivery has been an integral part of agile methods since the very beginning.
- smrtinsert 10y agoIs it continuous because the build is taking forever and never seems to finish?
- emblem21 10y agoProjects die all the time. Even languages can (mostly) die. The death of a project is a valid part of a project lifecycle and knowing how it dies can affect how you deal with previous project phases. Agile never assumes project death is a reality. It philosophically implies that you can always measure and iterate your way to the next phase... but that's just not true. No one measures and iterates their way to a dead state on purpose and yet, projects end up there all the time. So how are the projects getting there and what is Agile doing about it? And don't give me the Agile vs. "Agile" argument. Assume a flawless execution of agile principles with completely accurate measurements and successful iterations took place when answering that question. To me, agile just assumes infalsifiability because it refuses to acknowledge, let alone, prepare for project death. And worse, according you agile, you can even measure and iterate your way out of the grave. The operation of a projects has more in common with biology than immortality. Treating projects like immortals flies in the face of the reality of project lifecycles and it brings very bad mental states to problem solving. It makes far more sense to treat a project in lifecycle phases (birth, child, youth, adult, mature, elderly, dead) than assuming a singular monolithic philosophy that completely ignores the arc of a project. A: "The code base is too unwieldy, no one understands it any more" B: "Oh, just measure and iterate" A: "But that just creates more unwieldy code!" Agile makes sense as a subphase of a project lifecycle for when that lifecycle is spinning its wheels in the mud, not as a end-all-be-all philosophy. TL;DR: Agile should used if a project stalls, not as a guiding philosophy.
- terryf 10y agoClearly the article is just a thinly veiled advertisement, but leaving that aside: Apparently the author hasn't really read the agile manifesto, because nowhere does it talk about scrum or sprints or xp or any of those things. The agile manifesto is essentially a few sentences, that very eloquently say "Don't be a dick and understand that the product people or customers don't really know what it's supposed to do either." Much like the bible took Jesus's essential point "Don't be a dick." and wrapped a terrible mess of a system around it, the various agile methodologies have done the same, but the essential point of the manifesto is as relevant today as it was when it was invented. (Note: I'm not actually religious, the Jesus thing was just a comparison)
- dimino 10y agoThis declares Agile dead without explaining specifically why. From what I gather, Agile is "dead" because no one actually does Agile, and only takes the "grab bag" of Agile terms without going fully Agile. If no one's doing Agile, how could it be dead, since it was never alive? Maybe we should start trying to actually "do" Agile, to see if it might work, since no one's ever tried it yet, according to this blog.
- WWKong 10y agoThere will be many comments pointing, "agile works great when implements the right way". While that might be true I'm willing to bet good money that agile has turned out to be really bad for 90%+ of the teams. I tried hard to save my org from agile and failed. Everything crashed and burned soon after.
- mywittyname 10y agoThis is my experience too. Companies bring in agile consultants to tell them how to release software better. But things never improve, and in two years, they do it over again (but with a different buzzword). If your company has trouble developing software, the problem has nothing to do with development processes. The problem is always management.
- morgante 10y agoI stopped reading at "Agile had a great run in it’s youth by taking on some obviously bad practices such as 'Waterfall' software development." Nothing about waterfall is obviously bad. It's how most engineering projects are done. Heck, it's how most projects generally in the world are done. There's a reason it took a long time to move away from waterfall. It solves obvious problems and meshes with how the rest of corporations typically operate. In fact, with software delivery methods which were dominant back then, agile probably would have completely failed. --- In the end, I ended up reading the full piece. One doesn't get much more oblivious and buzzwordy than this: > We are now more squarely in the age of Microservices, Mobile first, Polyglot, post-Java JVM languages, GitHub, Docker and the emergence of a world being eaten by Software. How is this piece on the top of Hacker News? This piece reads like it was written by a marketing consultant with no idea what these terms actually mean or how software is actually built.
- fuck_google 10y agoThe waterfall model (of software development) wasn't even originally (by Herbert D. Benington in 1956) meant to by applied in a strict top-down fashion, but in an incremental and iterative fashion and by making use of prototypes, which has probably always been clear to everyone except clueless managers with no software engineering background. http://sunset.usc.edu/csse/TECHRPTS/1983/usccse83-501/usccse83-501.pdf http://sunset.usc.edu/csse/TECHRPTS/1983/usccse83-501/usccse...
- wmonk 10y agoYou are not wrong, it is written by the CMO of Gradle.
- emitstop 10y agoYeah and I like how he goes in on 'Agile Gurus' and then at the end of the article plugs his continuous delivery conference like it isn't the exact same thing in a different hat.
- vorg 10y ago> We are now more squarely in the age of Microservices, Mobile first, Polyglot, post-Java JVM languages Gradle provides only one language, i.e. Apache Groovy on the JVM, for specifying build configuration info. Before talking about "Polyglot, post-Java JVM languages", perhaps Gradleware needs to eat its own dogfood and provide an API so users can write their build configs in Jython or JRuby if they want. Be polyglot before preaching it.
- ricardobeat 10y ago"Agile" is not selling tickets anymore, let's come up with a new buzzword!
- digi_owl 10y agoTime to print some new bingo boards?
- UK-AL 10y agoContinuous delivery is basically another form of Agile
- mschuster91 10y ago> If you’re unable to keep pace with the rate of change of the open source components you depend on, you will be frozen and stuck and unable to ship software properly, a state we at Gradle call “Build Hell”. Or do it like anyone who wants to build a business that lasts longer than 2 years: use stable, battle-proven software only and don't run after every hipster trend (remember EmberJS and friends). Before you use any software component, evaluate its support lifecycles and how well it is being maintained - especially with the trend of "modularization", where stuff like a string pad function is a separate module, every additional dependency you pull is a potential security issue. Oh, and don't make the cardinal error of putting your node_modules/vendor folders into .gitignore. THAT is build hell once someone unpublishes a popular module...
- cha-cho 10y agoNot hyperlinking to the Agile Manifesto in the second paragraph? Man that's cold.
- tempodox 10y agoI'm sure one can always find the next buzzword to sell seminars about.
- moonshinefe 10y agoThe problem with these buzz words is it seems most people can't seem to agree on what they mean. This author seems to think continuous delivery replaces agile, case in point. It'd be nice if people could just layout concrete development / release plans and not assume everyone has the same interpretation for the buzz word that happens to be in vogue for a particular management team. Oh, you didn't read all those development methodology books?! I'd sort of like to speak plainly and get programming done, personally.
- fmueller 10y agoWe really need a bullshit register for this kind of people. They should not be able to get away unpunished for releasing something they already know is bullshit.
- triplesec 10y ago"So to eulogize Agile absolutely does not mean to go back to Waterfall, by no means." I think the author is confusing eulogize for euthanize, which amuses me.
- daemin 10y agoWith all this talk of Agile, continuous delivery, Waterfall etc, it reminds me of a Software Engineering course I did at University. Specifically one of the methodologies mentioned which was a Spiral model. The gist was that instead of having one monolithic Waterfall process, you would still do the steps in waterfall, but you would release more often and have smaller releases. So that after a few iterations you would spiral in on the desired solution. Upon reflection this seems like a proto-agile methodology, and because it doesn't have its own set of buzzwords and extra processes it seems like it could be a good reactionary (as a reaction against full Agile) methodology to use.
- geodel 10y agoI don't know what to think about it. The gradle.org website screams consulting with its slickness and free user guides/books etc. It does not look like honest, no-nonsense build software. The source code is about 6000 Java files + 3200 groovy files besides many others. To me it appears excessive and over designed software. I will be very reluctant to use a build software which needs 300+ pages user guide. TBH it is entirely possible that I just do not work on such complex software projects which needs tools like these.
- vorg 10y agoAfter James Strachan was knifed 2 years after he created Apache Groovy, that ecosystem has been all about consulting and conferences. Software such as Grails and Gradle is shoved down people's throats with promises of managing complexity and giving users choices, but in reality these tools add complexity and the documentation obscures. Then the sales calls start touting conferences and paid services to manage it all.
- Zigurd 10y agoAgile is "dead" because it isn't practiced. Where and when it is implemented, it's just fine. But 90%+ of "agile" is actually a sloppy, lazy, underspec'ed waterfall process hoping to achieve results in a stealth fixed-bid model, tracked on a kanban board. The other side of the coin is that defending agile falls into the No True Scotsman trap too easily: Since people don't practice agile, failed projects aren't agile. Well, of course. The real problem is how do you get the people who could be doing agile to be motivated to access the benefits of agile, and how do you get the borderline cases to acknowledge their limitations and address them.
- vlehto 10y agoI used to study construction engineering and now I work in construction. "Waterfall" is still in use and going strong. Applying that directly to coding seems bit stupid. I then swithed major to mechanical engineering, and there "toyota production system" is the thing. Agile and lean are just taking the underlying idea bit further. The original idea is to eliminate intermediate storages. This happens by making every production cell to order shit from previous production cells via kanban card. Previous idea was to just optimize volumes of every cell while giving zero fucks who, when and why the product was needed. But even inside the realm of mechanical engineering this sometimes is plain stupid. For example the workflow of large castings doesn't follow rythm of manufacturing cells. It follows the rythm of curing molds, heating metal and waiting the metal to cool down. What is "Agile" in software seems to follow TPS somewhat. You do one unit of work, you cash that in and start on second one. Id guess it's just coincidence that short compiling times and intermediate storage elimination happened during same timeframe and that resulted one term for both "agile". I have very limited experience on coding, but neither of the previous seem to fix any underlying hard problems in coding. When I code, I struggle with interfaces, specs, debugging and data flow. The only thing that comes close to coding is design of mechanical parts. But that has lot less degrees of freedom. And there seems to be pretty much zero management fads applied to mechanical design anymore. The only thing everybody is saying is that "try to keep open mind in the beginning of process. And spend some serious time defining your problem, because that's what affects total costs most". The rest is just going by gut feeling. We have ISO and ASME, but still interfaces are some of the most tricky subjects around in mechanical design. I'd expect the next meaningfull paradigm for coding to focus on interface design, as it's the one that requires communication between human beings. And it sets limits to what individual coders can achieve. "Never stand between craftsman and his professional pride" Quote by Kalevi Aaltonen, but I guess he got it from somewhere.
- jedicoffee 10y agoThis is just an advert. Can we please stop supporting all of these "XYZ is Dead" articles with no real solutions provided and an obvious unlying financial agenda.
- dmtroyer 10y agoAm I the only one that thinks this 3 column layout is atrocious?