16 ms·

Requirements volatility is the core problem of software engineering

• beefield 7y ago
  As someone somewhere said, writing software to a spec is like walking on the water - Easy when it is frozen.
  • guggle 7y ago
    Still slippery though.
    • Aeolun 7y ago
      Better make it a rough spec then.
• fouc 7y ago
  Greg Young described a good way to deal with requirements volatility: optimize from the beginning to be able to delete your code, and structure your code so that any part of it is no bigger than 1 week's worth of coding. So that any part can be re-written in 1 week. https://vimeo.com/108441214 https://vimeo.com/108441214
  • StreakyCobra 7y ago
    That was an insightful talk, thanks for sharing!
• asplake 7y ago
  > Requirements change. Every software engineering project will face this hard problem at some point. > There is really only one answer to this: you need to find a way to match the requirements-development-delivery cycle to the rate at which the requirements change. Honestly, I believe that much of the problem is with the word “requirements” and I so wish we could kill this use of the word. Bottom line, for systems built for humans, ploughing through backlogs of requirements is the path to mediocracy (or worse) – as the OP discovered. A less misleading framing: you need to find a way to match the delivery cycle to the rate at which understanding changes. In other words, your development process is a learning process.
  • asplake 7y ago
    Shameless plug (I’m paraphrasing myself in the “mediocrity” line above): Right to Left: The digital leader’s guide to Lean and Agile https://www.amazon.co.uk/Right-Left-digital-leaders-guide/dp/1789555310 https://www.amazon.co.uk/Right-Left-digital-leaders-guide/dp...
  • artsyca 7y ago
    100% agree learning is the core problem people in large organizations really don't know how to learn and the typical corporate environment is the perfect quasi academic environment geared towards pursuing metrics that amount to chasing grades
  • notduncansmith 7y ago
    This absolutely. As understanding evolves, requirements evolve. Some domains are well-understood enough that this process can be done up-front a-la waterfall, but more often these domains are so dynamical that the only way to understand them is incrementally, one dynamic (or metadynamic) at a time.
• deleted 7y ago
  [deleted]
• 29athrowaway 7y ago
  Agile is about giving developers the illusion of control, so they are more comfortable committing to an endless cycle of nonsense.
  • throwaway15392 7y ago
    That’s a really interesting perspective. I’m doing a waterfall on my current project and it just feels more right
    • EliRivers 7y ago
      Each software development methodology seems to be about mitigating particular risks. Agile seems to be mitigating the customer not knowing what they want the software to do; tiny little software cycles, little steps, making the customer look at it frequently and saying what they think. There are software projects with high-quality customers (sadly so rare) for which that risk is much lower, and as such agile is a bad fit. There are certainly software projects where waterfall is a better fit, mitigating against different risks.
  • artsyca 7y ago
    That's when done in a factory feature farm where you've already sold your control for the safety of a steady paycheck Try selling a really agile methodology to a client of your own before you jump on the turnip truck When done properly it gives the client immediate results with little up front commitment or risk and gives you all the control you could want as long as you don't mind being untethered from the communal trough and putting your reputation on the line at every iteration
    • 29athrowaway 7y ago
      What comes first, feature creep or agile? I would say that agile has helped create the conditions for the proliferation of tech debt mills, because it empowers product people while disempowering engineers. "Rapid and flexible response to change" is really just bruteforcing ideas leaving a trail of tech debt that makes developers miserable.
• atoav 7y ago
  It is funny to compare that to traditional product design. Let's say your goal is to design a chair. The most important tools in your toolbox are variants and iterations. The worst you could do as a designer is constantly working on one (final) chair. Because every change that goes aginst the initial concept will have you saw pieces away and glue them to other spots till you end up with a completely irrational whole. The problem is of course, that a low effort design prototype still looks and feels like a low effort design prototype. But the customer sees 5 variants of the low effort prototype and can decide which one is iterated on further. If you program a low effort software prototype, it should still kinda work and this is where the customer would decide to run with it. Also software (like graphic design) is a field where people without any skill tend to have strong opinions about how things should look or work, which makes manipulazing the customer into taking a decent solution part of the job.
  • Ma8ee 7y ago
    But the code is the design. The actual building is done by the compiler (or equivalent). So the important lesson is to budget for iterations of the design and not putting too much effort into the first sketch presented to the customer.
  • taurath 7y ago
    > Also software (like graphic design) is a field where people without any skill tend to have strong opinions about how things should look or work Business too. You do not have to be a good strategist to “succeed” as a VP in a medium or larger sized organization. In fact, you can be downright terrible.
    • atoav 7y ago
      It is why I ultimately stopped taking on much graphics design work and did more film sound mixing jobs — there is so much less people who think they have the experience to tell you precisely what they want and much more we trust you and do your thing. I am slowly starting to get the idea behind medival guilds..
    • steve_g 7y ago
• drenginian 7y ago
  It’s not a problem of software engineering, it’s a property of software engineering.
  • cjfd 7y ago
    Yes, that is very true. If changing and complex requirements are a problem, you are doing it wrong. This is the main reason why code quality must be as high as possible. It is the best chance there is to be able to accommodate new and changing requirements in a reasonable time frame. It is also the reason why automated tests are a necessity. Otherwise it is way to easy to satisfy one requirement while not noticing that at the same time one is destroying three others.
    • bryanrasmussen 7y ago
      If the subject is Software Engineering and you said "If changing and complex requirements are a problem, you are doing it wrong" the it in that sentence should be Software Engineering - but the changing and complex requirements seldomly come from the Engineers.
      • cjfd 7y ago
        No, they do not come from the software engineers. It is like being a DJ who is taking requests. You are not playing music for yourself but for other people. It the DJs task to make them sound good. On the other hand, one sometimes also needs to clarify what is wanted because the customers will ask for a rock song with a slight edge of metal in it and as the DJ you will need to know what song fits that description.
        • bryanrasmussen 7y ago
          It seems that when I say that requirements seldomly come from the software engineers you have somehow misunderstood me as meaning that requirements do come from the software engineers?
• bryanrasmussen 7y ago
  This is somewhat triggering for me right now as I am just getting done with a project that is quite a few degrees hotter on the Requirements volatility scale than is currently assumed.
• perlgeek 7y ago
  The article talks about the one contract that had the requirements fixed -- but then fails to talk about how contracts should be laid out to embrace changing requirements. People have known for a long time that volatile requirements are a core problem, but that typically hasn't really affected the way software and software development services are procured. This might be different in other parts of the world, but my impression is that even custom development contracts are procured the same way that you would a big shipment of physical goods, which is just insane. Once you work as a developer in a project that was procured in such a way, it's already too late. The knowledge that requirements will change and will totally disrupt your development process is there, and it doesn't really help you.
• bostik 7y ago
  The article mentions how one part of change is that regulations may have changed. I work in a heavily regulated industry, and am dealing with a set of regulators nearly all who depend on just one particular auditing company to ... effectively write their regulations for them. To the point where a new jurisdiction happily refers to their draft regulations as documents prefixed with the auditing firm's name on them. (This is not a joke or hyperbole.) That particular company has trained their own workforce to evaluate acceptance criteria according to their internal workflows and practices. This in turn means that almost all industry regulations are geared not towards functionality, but to make sure the auditing company has the least amount of training to do. As far as I am concerned, this is a particularly perverse form of regulatory capture: it's not even the industry at large writing their regulations, but an already entrenched gatekeeper acting on their own interest, crippling both the regulators and the companies in the industry. Now, I have no problem with regulations as such, because for most parts the rules tend to make good sense. But I do have a problem with regulations shaped after the desires of this particular auditing company. Instead of focusing on results, quality, transparency, accuracy, recoverability and functionality, they have a fixated view on particularly dubious change management processes. I am convinced that at some point in history, someone has done extensive research into 70 years of software engineering best practices - and gone to extreme lengths to expressly reject as many of them as possible. Two examples: they insist that even unit tests MUST NOT be written by the engineers who work on the code; and they are mortally afraid of the idea that engineers who work on a problem could ever understand and evaluate the problem. (Not to mention that the very concept of a workflow tool is completely alien to them.) The end result is that you can either try to do software well, or you can try to do it according to regulations.
  • BlueTemplar 7y ago
    Understanding and evaluating the problem is the main job of an engineer?!? (Compared to a technician...)
    • bostik 7y ago
      It's definitely part of the job. If you don't understand what the problem is that you're trying to solve, how can you verify that the constraints you are working with actually make sense?
• danielovichdk 7y ago
  Developers who believe they can forsee the future are more dangerous than missing business requirements. The problem with missing business requirements are that developers often are either to focused on writing the code instead of actually understanding the business. You cannot build something you do not understand. Understand small and expand your understanding. Code is not the goal, it never is. It's a means to a goal. Another thing about software is, that a lot of it should never ever be written. It's the last thing you do, is write code for overcoming a challenge, because rarely you really need it.
  • ausimian 7y ago
    Nicely put. In my nearly three decades of software development, the most successful of my various colleagues have been the ones motivated by understanding the problem and its wider context, rather than the tech/process/language _de jour_. This is a multiplier because it allows them to detect and ignore non-problems and work on problems whose solutions _will_ deliver value.
• zuckluni 7y ago
  I disagree with the title. I've used waterfall and still found engineering hard. Even you have a bulletproof requirements document, implementation and engineering still produces unforeseen eventualities and unexpected consequences. I think software engineering is hard primarily because it's the coalface between abstract and concrete. We're wired to be great at concrete, but capable at abstract. With software it's like we can get ourselves into a perfect storm of intractable-for-us problems. Other forms of engineering, civil, mechanical, etc are still really hard, but I think we're better wired for them because they're less abstract, more concrete. But in software, abstraction is part of your bread-and-butter daily-grind tool-kit.
• robocat 7y ago
  Don”t rewrites also fail all the time, even if requirements are not expanded? Rewrites would mostly be successful by the articles premise.
  • Nasrudith 7y ago
    Well rewrites have two conflicting goals - simplifying the code/improving performance and consistency with the old version. Even if the requirements are nominally the same "unwritten" ones pop up
    • robocat 7y ago
      Sure, but “unwritten” requirements pop up all the time for any requirements, so the two situations are still broadly equivalent.
• EliRivers 7y ago
  The only software project I ever worked on in which the customer didn't report so much as a single bug had the requirements done properly, up front, and agreed all round. Of the thousands of identified requirements, I think less than ten changed over the lifetime of the project, and each change underwent significant examination for consequences. The project was waterfall all the way. The quality of software that can be built if you know before you start what it's meant to do, and that doesn't change, is astounding. Truly astounding.
  • temac 7y ago
    The funny thing is that most people never even attempt to do that, and then still manage to complain about it being impossible. Yes in some projects that can be harder, but I'm not buying the ambiant: "in most projects". I actually think in that in most projects, a good part of requirement analysis can be put upfront, and of course a tiny bit will still evolve, but not enough to prevent doing things properly. That does not impose to have too long projects, btw. Just cut them in phases and/or pieces. Feedback cycles are important, but this is still an equilibrium, and in some projects I don't see how 2 weeks feedback cycles without proper requirement engineering would be any good. Maybe one problem of software development is that it is an ever growing industry, so the mean programmer is always young and inexperienced. Maybe things will be less impulsive with the eventual end of that growth.
    • BlueTemplar 7y ago
      The number of feedback cycles is pretty much what defines waterfall vs agile. And it's hard do do a proper waterfall when you hardly have an idea of how to even approach the problem.
  • matsemann 7y ago
    I have worked on huge government projects that has been specced and planned for years before arriving at my team's desks. It takes a few days before we will have questions. Things not defined good enough, inconsistencies, glaring holes etc. I think having all reqs upfront is a utopia that will not happen. Those projects I was involved in would have been better if the reqs and scope was done in conjunction with us implementing it.
• Gibbon1 7y ago
  > As a consequence of this, software is never finished, only abandoned. Ditty of mine from around 1988 or so. The hardware is old and obsolete but the software never is complete. One thing I realized a long time ago was that you need enough resources to keep up with the requirements drift or you will never finish. That's what's behind YAGNI and Minimum Viable Product. There is this other thing which is a successful product 'creates it's own weather' as far as requirements go.
• AmericanChopper 7y ago
  Perhaps that is the core problem, but that problem is caused by not knowing the requirements to begin with. Which again is usually caused by not knowing what your customer wants (which you should be able to do, even if they don’t know themselves what they want), or not knowing who your customers are. Contract work is the best environment for fostering a culture of not knowing what your customers want, because it is the ultimate exercise in fence-throwing (often to somebody who’s just going to throw it over yet another fence). Problems tend not to change so dramatically over the course of a project. What usually happens is some stakeholder realizes at some point that they didn’t actually understand the problem the first time around, and thus need to change the requirements. Even significant regulatory changes won’t usually cause that. In almost all cases, regulatory changes have a significant amount of time between announcement and enforcement. Making your development practices more responsive to change is a good goal, but it doesn’t solve this problem. Because this problem is typically created before the first line of code is written. If the defined requirements don’t actually solve the customers problem, then they’re going to be delivered a non-functional solution, whether it takes one year to deliver, or one day.
• jokoon 7y ago
  This quote is old and explain very well why early software was often high quality: > “Walking on water and developing software from a specification are easy if both are frozen.” ― Edward V. Berard The more you plan ahead and the less you change goals while writing software, the less problems you have. Software is the only field of engineering where you can change things at any point in time. But it doesn't mean you HAVE to change things. Software should really take lesson from other fields of engineering. Companies always want to cut costs, and with software, they really can.
  • BlueTemplar 7y ago
    The ongoing discussion in the EU about a legal obligation of X years of update support comes to mind...
• kabes 7y ago
  I often hear people say that software engineering is a joke compared to civil engineering or other kinds. But they forget that when a civil engineer designs a bridge he doesn't start with: "We don't know exactly what weight it should support yet, but just start building the bridge already". And he doesn't finish with a: "Ah, turns out we wanted a tunnel instead of a bridge, can we change that next sprint?".
  • catmanjan 7y ago
    I often hear people use that logic as a reason why software doesn't qualify as engineering
    • chrstphrknwtn 7y ago
      Do you share the opinion that software doesn’t qualify as engineering? I’ve always thought it is a little bit of a stretch.
      • lifeisstillgood 7y ago
        My view is software is literacy not engineering or science. It tends to make more sense for me. A book that starts out as a romance is just as hard to convert to a spy thriller half way through as a bridge and a tunnel (Ok not total effort but in terms of percentage of rework)
        • Noumenon72 7y ago
          I think you mean "literature".
          • lifeisstillgood 7y ago
            Yeah. I use the term software literacy a lot so my bad
      • TheOtherHobbes 7y ago
• hden 7y ago
  > Requirements change. Every software engineering project will face this hard problem at some point. Rich Hickey calls this a 'situated' program in his talk from Clojure/Conj 2017, where the program has to deal with information and real-world irregularities for extended periods. While agile disciplines help you from one perspective, your tools (e.g. program language) might also help you solve some of the problems. In this framing, Clojure certainly tries to help where the it matters most. Highly recommended to read the transcript or watch the video, even if you are not interested in the language itself. Video: https://www.youtube.com/watch?v=2V1FtfBDsLU https://www.youtube.com/watch?v=2V1FtfBDsLU Transcript: https://github.com/matthiasn/talk-transcripts/blob/master/Hickey_Rich/EffectivePrograms.md https://github.com/matthiasn/talk-transcripts/blob/master/Hi...
• temac 7y ago
  Just to nitpick, there are counter examples of finished but not abandoned software. As usual, Tex comes to mind. Or they just could. E.g. we could probably take the current Python 3 and freeze it and debug it for 20 years, at which point it would be basically finished, and maintenance could still continue (but way much less would be needed) IMO a good part of requirement volatility is a self inflicted wound. Some are essential, of course, but some changes are for the sake of changing and giving PM, UI, and software engineers jobs, and I even don't know lot of people who appreciate too many gratuitous changes in e.g. software GUI. My general advice is to slow down. And fucking finish things before starting new ones. We don't let half-constructed bridges around just because we start to build new ones with fancier materials.
  • BlueTemplar 7y ago
    I guess that slowing down doesn't pay well in an industry where a startup can get from zero to billion in a few years?
    • temac 7y ago
      Probably that plays a role. However, not everything is a startup. Accumulating technical debt during even just a few years like there is no tomorrow is also a non negligible risk. You can also go from billion to zero in a few years...
• chiefalchemist 7y ago
  The two most common patterns I've experienced: 1) Poorly communicated goals. Sometimes not communicated at all. If you don't know where you're head and _why_, it's damn near impossible to get there. 2) Wants being confused with actual business needs. 3) Clients / stakeholders not able or willing to put in the time for essential discussions and critical decisions.
• 32gbsd 7y ago
  There is a whole industry of people who are in the business of telling programmers what to do but not how to successfully complete a project because they do not know anything about how to actually finish the things they tell people to start. "Just use agile everything will be OK!"
  • 32gbsd 7y ago
    Oh and lets not forget the project managers themselves that blame the client/users instead of their own inability to meet the requirements; http://owensoft.net/v4/item/2368/ http://owensoft.net/v4/item/2368/
• ctdonath 7y ago
  The key difference between software vs all other engineering: building it is instant & free & repeatable, vs expensive & slow & singleton. If bridges could be replaced in minutes for pennies, we’d build them iteratively too.
  • ken 7y ago
    Buildings certainly do change. I just finished 3 months of work on a structure that was "finished" 20 years ago. We had the client coming to us with changes to our changes several times a week. The problem with software is that we don't build it in a way that makes changes easy (or at least not all the types of changes that clients frequently want to do), and we do a terrible job of communicating the costs of changes. Give me any program, and I can change a couple words in its requirements which would cause more than half of its lines to need to be changed. That's just how we write software today. (We diligently made 'time_t' a typedef, and then we embedded the physical size of it in every file format and API and protocol so we can't actually change it without breaking everything.) Maybe we need a new type of specification system, to encode the distinction between "this is a decision which is immensely expensive to change and will necessitate rewriting half the program" and "this is just part of the facade and we can change it cheaply at any time".
  • closeparen 7y ago
    Exactly. Design is code, construction is compilation.
• Tainnor 7y ago
  By now, I'm rather convinced that the "core problem" of software engineering is that it's too easy. Yes, despite the myriad failures in delivery, once you actually get some working software onto the market, its value immediately multiplies as a sole function of your marketing (and, incidentally, I think this is one of the reasons why US based companies are more successful than e.g. European ones: they can start out with a big single market). And even when you're not profitable, VC money is being pumped into the most ridiculous of companies right now. Of course, when faced with this kind of situation, why bother getting things right and professionalising? I've seen big companies with the most insane development cultures where things would constantly break, and yet it didn't really have any big negative impact on profits. Maybe the well will dry up at some point, but so far it doesn't look like it.
• mannykannot 7y ago
  Requirements volatility does not fully explain the frequency with which basic security flaws keep reappearing, long after they have been recognized and documented.
• longtermd 7y ago
  "Requirements volatility" is just another word for: A/B testing software :). Let's get used to it
• rossdavidh 7y ago
  I am reminded of how linguists, when trying to document a language from one of the last living native speakers, don't just ask them to tell them the rules of it. They have to task questions like "how would you say this?" Then they try to reverse-engineer the grammar, syntax, etc. In most cases, the people who are giving the requirements either: 1) don't actually know them (e.g. they are in upper management but the software will be used by line workers) 2) have internalized the details of the process so long ago that they are essentially subconscious now. They would tell you the real requirements if they could, but they just can't, they will instead tell you what they think the requirements are. Then, once you build it and they try to use it, like the native speaker of a language hearing you speak a sentence in it using the grammar rules they just told you, they will immediately know that it's wrong. So, the best way to find the _real_ requirements for the software, is to build the software, and have them try to use it. Stop planning and endlessly documenting someone's fantasy or best guess at what the requirements are; the only way to really discover the requirements is to build the thing.
  • AndrewKemendo 7y ago
    Seems like that's why startups with a founder that is solving their own problem are more successful than ones doing otherwise.
    • newscracker 7y ago
      That doesn’t make sense to me as a reply to the comment above. Such startups should then be useful only for the founder. The GP’s point is to build and get feedback from the users to revise it continuously. That’s how you know you’re solving the problem for someone who seems to have the problem.
      • Jarwain 7y ago
        The idea is that the founder was once, or still is, the "user". They know the problem because they had the problem, recognized that software could solve the problem, and started a company to make that software a reality. Because the founder is a user, the founder knows what the solution should look like, and can guide development in the right direction. There's a tighter feedback loop when the user is inside your organization, and is managing the product itself
• pbhjpbhj 7y ago
  Is it primarily requirement volatility, or primarily ill-defined requirements? (If it's the later, that's some super-irony.) That would explain at least a couple of further issues mentioned here. Like rewrites: software doesn't always define it's own outcomes well; the requirements don't change they're just poorly defined. Requirements changing, and feature creep are subtly different too -- with static ill-defined requirements features could change as the requirements in a particular facet of the software become more clearly mapped out further on in the project. For example, in the Berlin airport situation (in a comment here), adding a new floor could be due to a realisation that a static requirement for floorspace want going to be obtained, because (say) a static requirement for through-flow hadn't been fully defined and expanding the capacity to meet that requirement then limited the available floorspace. None of the requirements needs to have changed. Perhaps that's to much of a philosophical distinction. (Not a [software] architect, or project manager or anything, feel free to tell me I'm talking rubbish.)
• heymijo 7y ago
  > The goal of software engineering is to make that development predictable and cost-effective. Is this true?
• mobjack 7y ago
  I change the requirements of my personal projects all the time. Once I get a prototype working I get lots of ideas of how to improve things. I also see that some of my initial plans did not work I out as I envisioned and have to iterate on them. If I can't get the requirements right on my own projects, then I have no expectations that others could do so either. Have the expectation that requirements are wrong on any project. It is better to embrace that these will change rather than try to fight them.
• xamde 7y ago
  Requirements are hard, but the core problem of software engineering is complexity.
• physicles 7y ago
  If requirements volatility is the core problem, the next question to ask is, Why is this the core problem here and not in other engineering disciplines? I think it stems from a mismatch between the perceived cost and the actual cost of changing software, which one of the first comments on the article captured: > That’s my take – the perception that software is simple to change, which stems from the lack of understanding of its inherent complexity by users, and the fact that it is, up to a certain point – is what makes requirements volatile. Part of the problem too is that the actual cost of changing software varies by an order of magnitude or more, depending on how fluent the developer is with the tools they’re using, and how good they are at accommodating change. If that’s not something even we as a profession (if you can call it that) have been able to reliably quantify, expecting a client to understand it is beyond the pale. I’ve been programming for most of my life, so if I see an app then most of the time I can get a sense for how long it’d take to build. But I still have this nagging feeling that building software — the act of translating what’s in your head into working code — seems to take way longer than it ought to.
  • xorcist 7y ago
    > Why is this the core problem here and not in other engineering disciplines? Software is the blueprint of a process. Software engineering is basically the art of exact specifications. Once you've unambiguously specified what it is you want, you're done. The rest is pretty much an appropriate language an a compiler but we have plenty of those.
• DanielBMarkham 7y ago
  <rant>I don't think most people know what they're doing when it comes to managing the delivery of software. The field is full of canards, facile simplifications, and self-referential, circular reasoning. A few examples. - The problem is requirements. Is the system broken? Yes. Do the requirements say for it to be this way? Yes. Must be broken requirements, right? Since requirements are the "driver" of the process, if the process is broke so must be something about requirements. - Software is never done. Bullshit. Do I need somebody to reprogram my decades-old mp3 player? I do not. Would it be nice if somebody did? Maybe, but it's not required for me to enjoy the software. The software is written, does its job, and needs no maintenance. It's done. There's plenty of software being updated today for pretty good reasons that for all intents and purposes is done. Just nobody wants to admit it. If it's possible to add stuff or update it, we do. It's what we do. - FTA, "...Requirements change. Every software engineering project will face this hard problem at some point..." That's true, but woefully incomplete. Your job creating software is not to meet the requirements, it's not to change and add stuff as the requirements change. That's viewing the work, once again, as requirements-driven. No matter what your process or paperwork, the work is ultimately user-driven, not requirements-driven. Your job is to scope a domain, anticipate change in that domain, and provide easy-to-use configurable software that anticipates that change. You do that by knowing the users and the work, not by reading requirements or responding to updated requirements. That kind of thinking removes the key piece of the entire work, the user. By the time somebody gives you a requirement, it's too late. Your design is whack. How do we make aviation and space travel gear safe? We fly the hell out of it. What's the wrong way to go? Build one-at-a-time and ask for changes and complete reworks for every new project. How do we build software today? Like we used to build rockets; using the wrong metaphor. We need reusable, configurable, capabilities-driven software, not endlessly worked-on huge hunks of bytes from BigCorp feature factories.</rant> EDIT: Just to clarify the rocket metaphor, we'd be far, far better off using COTS tools and writing minimalist, simple code that only does a few things, then pounding the hell out of it with actual usage to figure out which "axes of change" we missed. Instead, more and more everything has some unique tech stack, a byzantine testing and deployment deployment system, the entire thing fun of tons of complex one-of code everywhere ... then we stick on new features one at a time every time there's something a user wants that it doesn't have. From a managing-complexity and managing-cost standpoint, it's actually worse than the Big Project rocket situation we had for decades.
• bob1029 7y ago
  I will say that our experience is that the happy path for virtually any customer is to ship the MVP as soon as humanly possible. This also means each new/revised feature after the fact. Only once the customer is actually screwing around with your app or feature will they start to develop a true understanding of what is unfolding relative to their daily life or business. Our customers have extremely high expectations for the quality of output from our application. Their entire business hinges on whether or not we marked a specific checkbox correctly on one of many insanely-complex forms. We started out on this project with a mentality of "its gotta be perfect and we gotta be done at some point". As a result, our development cycles dragged on for months with the customer testing everything all at once on a single "drop dead day". Thankfully, we were able to get away from this mindset. We went from 'almost killing the company' to 'everyone is extremely happy' simply by delivering features to customers on a daily basis. Having that nearly-immediate feedback on new code from the customer means that the responsible developer likely still has most of the abstract concerns loaded into their mental cache and can quickly iterate if needed. One other aspect that really started putting leverage behind us was building our own integrated tools for easily investigating exceptions or other issues in customer environments. If a user of our application experiences an exception, we are typically reviewing it within 5 minutes (without them having to report it to us explicitly), and if its a trivial affair, a build with a fix would be available for update that same day. Having the ability to trace user events through our application is probably the single most impactful troubleshooting tool available to us aside from the raw logs. Ultimately, all of the above is the acknowledgement by us that software development is a very hazardous affair, and that we need processes and tools available for rapidly engaging these hazards when they arise. The sooner you realize you have the wrong answer to a problem, the sooner you can go off and find the correct one.
• x3haloed 7y ago
  >In an agile project, ideally, there is a working partial implementation starting very early in a project, and observable progress is being made toward a satisfactory product from the first. Can anyone give a practical example of how this works in the real world? Like, what's a complicated workflow that needs automating, and how would you build it iteratively? Also, how could you predictably alot a time budget in this case so that you are not endlessly chasing satisfaction on a specific product or feature?
• sktrdie 7y ago
  A really big influence to me has been the work by prof Harel on Behavioral Programming (aka scenario based programming) which makes coding similar to how requirements change, evolve and sculpt the software. His take is much more pragmatic than the Agile manifesto hinting at entire new languages (live sequence charts) and paradigms (bthreads) where requirements can actually be executed This wonderful video by Harel himself is a good intro on these concepts: https://vimeo.com/167925763 https://vimeo.com/167925763
• mrdoops 7y ago
  This, along with the cost of development, is why I have a pet-peeve for hard-coded business logic directly in the code (in most cases). I.e. when a frequently changing business process like a finite state machine for an approval procedure is only change-able by a developer that means there's always the cost of that developer's "need-to-know" for a straight forward change in the business operations. The cost of a given change is greater than a declarative capability that took into account operational changes in the first place. That said hard coding business logic is often so much quicker to deploy that in many situations you just want to hard code the logic, deploy, get feedback, then introduce flexible to the kind of change needed then continue. If you have engineers who know how to ask the kind of questions that get to the real requirements (usually not juniors) you can have a maintainable code base. Worst case scenario is if you have the "yes I shall do anything and everything with my new code power" developers who just implement out of eagerness and conflict avoidance; this can be the worst of every world: hard coded business logic so convoluted only the junior knows how to make changes.
  • crgwbr 7y ago
    > This, along with the cost of development, is why I have a pet-peeve for hard-coded business logic directly in the code (in most cases). I’ve built systems both ways. Requiring a developer to make changes definitely has costs, but it does have benefits as well. Systems configured in data rather than code will almost invariably be untested and prone to configuration bugs. Overall, I’ve spent probably double or triple the time debugging configuration of complex business rules systems than I would have if it was just written in code and unit tested.
    • mrdoops 7y ago
      Agreed. I guess my point is that we need to focus more on making declarative business rules systems more tenable as an approach in general. If we consider the framework + CRUD generators as the most productive way to build a web app (probably has been since Rails) - that's a result of tooling built around an approach. What happens when we focus similar efforts of tooling towards these Rule Based components?
    • 7y ago
• Ericson2314 7y ago
  Honestly the desire for simple unit economics and legacy property rights really fucked it up. People pay for "a software", but what they really need is a change in the collective software commons. Of course, no one expects any change order to be the final one, so the the volitility is natural and expected.
• amelius 7y ago
  Hopefully the existence of this article will not make it legitimate for managers to change the specs all the time.
• moron4hire 7y ago
  After 50 years of activity in attempting to improve software project metrics with little to no improvement, we have to admit that we've been looking in completely the wrong place for effective change. It's not how the developers work that is the problem. We've changed languages, team sizes, project cycle lengths, everything. Except one thing. The one thing in common with all of these failed software projects is corporate, top-down management. I would say it's even gotten worse, to counterbalance the real productivity improvements we have actually gained from improved tools. You look at all the companies that can deliver software on time and budget and they have one thing in common: they aren't ran by Harvard MBAs. You look at all the once-great companies that eventually faded away into obscurity and they also have one thing in common: imposition of MBA-imposed corporate management structure to "cut costs" (aka, "throw out the baby with the bathwater"). It killed Bell Labs. It killed Xerox PARC. It killed Apple once, which then was reborn from its own ashes, and is in the process of killing Apple again. It's impossible to be a great developer in an environment that denies that there can be unique skills and knowledge to individuals. Anywhere developers are "resources" they will be treated as interchangeable cogs.
• WalterBright 7y ago
  That's true of any form of engineering, not just software. Requirements change because circumstances constantly change, and people simply are unable to imagine it completely beforehand. One has to build it and try it out. As software engineers, we build things to be adaptable to change. That's why it works to build things out of encapsulated components.
• ellius 7y ago
  As an addendum to this, I would frame the problem as "complexity," one aspect or symptom of which is requirements volatility. Complexity comes from two sources in software projects. The first is the domain. As other commenters have pointed out, domain experts are usually half-aware of their domain requirements because much of the complexity has been buried under their expertise and intuition. Domain requirements also inherently change over time as markets, professional standards, and technology evolve. So the process of development involves a shifting discovery of new aspects of the domain as things which were unconscious become consciously learned. The other aspect of complexity is the technology applied to the problem. Computer technology is inherently complex, and the imperfect mapping between domain problems and technology adds a third angle. The best books I've seen for dealing with these problems are "Clean Architecture," "A Philosophy of Software Design," and "Principles of Product Development Flow." The first two explain how to build good systems that encapsulate complexity and are geared towards changeability. Such systems are flexible as new aspects of domain complexity are discovered over time. The latter book takes a higher level view of how to design projects to cope with the discovery process in a way that is economically viable and justifiable to the people financing projects, and also in a way that arranges work so that developers can actually be productive and not become swamped by the complexity problem or bad processes and practices.
• carapace 7y ago
  The weird thing (IMO) is that computers are already universal machines, so why isn't any programming language already enough for any task? In other words, why hasn't Excel fully defeated all comers? It's widely known but seldom appreciated that Excel is the most popular and successful programing language in history. And not just a little. It wins by a large margin. So why do people still pay you and I to "make things go"? (Yes, that's a Pakled reference. https://memory-alpha.fandom.com/wiki/Pakled https://memory-alpha.fandom.com/wiki/Pakled) I think to answer this question you have to understand the difference between what we have now and what we could have. What we have now is a stack: OS, WM, "Desktop" -> Separate "Applications" often with their own GUI (in addition to the OS-provided defaults) -> Web "apps" where anything goes (up to and including "dark patterns" like fake widgets designed to mimic OS-level modal dialogs.) All of this is conceptual overhead that adds nothing to the achievement of the prime tasks (that humans are using computer for in the first place.) What we could have: I have two examples: The Oberon OS and Jef Raskin's work. https://inf.ethz.ch/personal/wirth/ProjectOberon/ https://inf.ethz.ch/personal/wirth/ProjectOberon/ http://www.projectoberon.com/ http://www.projectoberon.com/ Try it live in your browser: https://schierlm.github.io/OberonEmulator/emu.html https://schierlm.github.io/OberonEmulator/emu.html https://en.wikipedia.org/wiki/Jef_Raskin https://en.wikipedia.org/wiki/Jef_Raskin https://en.wikipedia.org/wiki/The_Humane_Interface_(Book) https://en.wikipedia.org/wiki/The_Humane_Interface_(Book) https://en.wikipedia.org/wiki/Canon_Cat https://en.wikipedia.org/wiki/Canon_Cat https://en.wikipedia.org/wiki/Archy https://en.wikipedia.org/wiki/Archy > These ideas include content persistence, modelessness, a nucleus with commands instead of applications, navigation using incremental text search, and a zooming user interface (ZUI). The core idea is to get "applications" and even modes out of the way, disintermediate as much as possible between the user and the raw computing power of the machine. In sum, we spend an enormous amount of time and energy working on things that have no intrinsic bearing on the tasks we hope to accomplish, largely due to the lack of awareness that it's possible to dispense with most of what is today considered normal UI. We are "turd polishing". If you get out of the users' way, they can implement their own requirements. - - - - Here's RMS talking about secretaries extending Emacs with Lisp: > programming new editing commands was so convenient that even the secretaries in his [Bernie Greenberg] office started learning how to use it. They used a manual someone had written which showed how to extend Emacs, but didn't say it was a programming. So the secretaries, who believed they couldn't do programming, weren't scared off. They read the manual, discovered they could do useful things and they learned to program. https://www.gnu.org/gnu/rms-lisp.html https://www.gnu.org/gnu/rms-lisp.html
• waterlink 7y ago
  My honest opinion is that software conceptually was created to allow for volatility of the requirements. If you want to have static requirements (or changing once per 5-10y), then that’s what you have _hardware_ for. Software has “soft” in the name for that exact reason. Embrace the constant change.
• hwayne 7y ago
  As part of a project I interviewed a lot of "crossovers": people who worked as both traditional engineers and software engineers. According to everyone I talked to, requirements volatility happens everywhere. Two civil engineers had to move a bridge. One "system engineer" worked for Boeing and was part of a team who's only job was to figure out how to reconcile existing work whenever they changed requirements.
• vanniv 7y ago
  Requirements are fairly volatile -- but the real problem isn't that the requirements themselves are volatile but that the true requirements are so poorly understood (and, thus, the apparent requirements shift rapidly as understanding of the problem domain changes throughout the software lifecycle).