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.
Here's another good example: what is the correct way to order multiple adjectives in English? If you are a native speaker, you probably don't have any idea, you just know that you say "an old big brown cardboard fridge box", rather than "a cardboard brown fridge old big box". The order is very specific and any deviation is obviously incorrect. Try it for yourself!
But any ESL student can tell you the order is quantity, opinion, size, age, shape, color, origin, material, purpose. We'd had to reverse-engineer the rules, and then teach it to newcomers.
I often use this as an example of an "unknown known" for most English speakers. We know how to order these things, but we don't know about the specific rules that govern their ordering and that we have (implicitly) mastered that.
There is human behavior and human beings' mental models of that behavior.
Your advice generalizes: As an engineer or scientist, never trust the models. At least not wholesale. They're simplified and inadequate, and the inadequacy is invisible to those using them.
> We wish we could tell you that there’s a predictable pattern here—that certain types of adjectives can always be complemented by both participles and infinitives, while other types are always restricted to one or the other.
> Unfortunately, no clear pattern emerges. Different adjectives simply act differently in different contexts.
In other words, sometimes there isn’t a rule, even after intensive analysis. There’s just a bunch of individual one-off decisions that each happen to work to solve their problem, without representing a coherent policy.
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.
> the only way to really discover the requirements is to build the thing.
I totally get what you're saying here and in an ideal world, this would be it.
Unfortunately, we don't live in that world, projects have budgets and need to be delivered within a given interval.
They touch other aspects of the business and are interlinked with marketing, support, legal, financing and so on.
I think it's our job as software engineers to figure out the requirements. One issue we have in our industry is that we do a sub par job of educating people regarding how software works and giving them alternatives instead of binary yes/no answers.
I would say most developers (and I'm generalizing here) lack the communication/social skills to do so.
The key here is to strike a balance between features, budgets and deliverables.
That's way the most appropriate way to develop software is to actually create it piece by piece with the client side-by-side.
Unfortunately, there is such software development platform in which software can be 'sculpted' as if it was a statue, with the client being able to oversee what the software would do at every moment.
In practical terms, here is how software development should go:
1) open an empty canvas (for example in your browser).
2) ask the client what they want. They will say, for example, they want to see a bunch of posts and comments below them.
3) create a list of posts, on the spot.
4) create the ability to add comments below each spot.
5) ask the client 'is this ok?'
6) he/she may say no, so delete the above and restart.
7) otherwise, proceed with the next question 'what else do you want?'.
In the back end, the development mechanism shall create the databases and code needed to handle the tasks in the front end.
After all, the only 4 things we want a computer to do are these: create/search/modify/delete information.
This was essentially the story of how we built a successful software company at cPanel. Our customers would describe things like “I want a button that does this” or “a script that does that” and we had to make many assumptions about what they really wanted. Finally after determine we were spending massive amounts of time on unused features, we developed everything as a workable “beta” feature. The ones that we got a ton of praise or complaints on kept getting developed. The ones with silence stayed the same.
This was before heat map software and click tracking which can do a great job of augmenting customer feedback.
The key part that we found out is that if you take this approach, you have to couple it with high quality software support. We hired and trained folks who knew the entirety of our business and tech (Linux, DNS, HTTP, hosting, etc). Our tech support reps were paid much more highly than others in the industry but it gave us more benefits than just being able to support customers when beta software was ship to prod, it also gave us a training ground for future software engineers, QA folks, SysAdmins, and Product Managers.
What I think a lot of people forget is that software is one piece of the puzzle in solving a problem, it’s absolutely not the whole solution. If you design a process based around connecting with customers on a regular basis and having feedback flow throughout your company, you won’t have to “make perfect features”.
I’ve only worked with a small number of companies since that have understood this. Most I’ve worked with have created communication silos and sit in rooms trying to dream up the perfect set of requirements.
A marketing person would add this: you invent first what people then want. In other words, the way to create the requirement for something is to build it, not merely to discover existing requirements.
The "build it and they will come" hints at that; it's saying that if you build something, people will see the value and then convince themselves they needed it all along.
"Build it and they will come" is a line from a movie about ghosts playing baseball (or the main character hallucinating), not advice applicable to building products.
Perhaps in some cases it approaches the linguists' approach, but the Requirement Elicitation I have actually witnessed looks more like a group of stakeholders in a room, writing on a whiteboard or something similar. Better is to make an MTP (minimum testable product), and put it in front of the user and have them tell you all the ways it's wrong.
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?".
As a web developer with 20 years experience I would argue that one web SPA project is more similar to the next than comparing two bridges and developers still can’t figure it out.
One difference is that a license is required to practice civil engineering. Most web developers, on the other hand, require large tools to do theirs jobs for them and recoil in irrational fear and disgust when standard DOM methods are used. I still have people argue with me that the DOM is slow even though all the evidence and browser vendors claim updates to the DOM is simply switching a bit in memory. In other words many web developers have utterly no idea how their platform works.
Another difference is that many developers cannot write. Everything about a bridge is planned in extreme detail before work on the ground ever starts. This level of planning is absent in software. Documentation is also largely absent. In most cases everything is an ad hoc mess. In any other industry this would be a cause of numerous lawsuits.
Another difference is that construction is treated as a business project with a dedicated project manager and project budget. Most business software, on the other hand, is treated as an operation. If you cannot discern the difference between a project (temporary) and an operation (living) your software will never be released as a product to a specified level of quality by a specific date.
I agree with you in principal. When I worked in web development many of my projects were clearly defined and similar.
However when I got into more creative development I found myself faced with unique problems to which the solution was unknown. The development process in this case is less like an implementation and more a exploration of the problem space.
This process is more like sculpting or writing a book or solving a puzzle. As you sculpt the next steps reveal themselves. As you write a story the plot emerges. In order to solve a puzzle box you probe the box.
Solving the unknown in bridge building is working through sets of equations and to solve for variables. It involves doing math.
Solving the unknown in software involves a similar working through. "Doing the math" for code involves executing code. It's faster and easier. Ignoring this is like restricting your bridge planning by avoiding CAD or doing the math by hand.
Yes, once a solution is mapped out the ideal would be a full rewrite. The benefit of software is that it can be modified and finalized directly like baking a sculpt or revising a manuscript.
If a button allowed the working schematic of your bridge to magically materialize, and changing the schematic affected the real world bridge instantly with negligible implementation cost then civil engineering would evolve in the direction of software development. It's not the other way around.
> One difference is that a license is required to practice civil engineering.
I've often wondered about this. Who exactly has to be licensed? Are there management layers in civil engineering firms where the license isn't required? I think my point is pretty easy to follow. I'd love for all of us to be licensed to practice software engineering, but I don't hold any hope that it would fix all of the other compounding problems that our industry has as it relates to product/project management and management-born issues.
For example, would being licensed stop executives at a triple-A video game company from prematurely announcing games / release dates, or accepting pre-orders for games that won't be finished on time, and forcing all of the people under then to scramble and crunch and do things that would generally be considered anti-thetical to whatever being licensed in software engineering could mean?
>Most business software, on the other hand, is treated as an operation. If you cannot discern the difference between a project (temporary) and an operation (living) your software will never be released as a product to a specified level of quality by a specific date.
I never really thought about that. There is so much truth to it and why so much Saas is a never ending feature factory! I assume Basecamp thinks of their Saas as a project and that's how they are able to escape the never ending Big Ball of Mud software craziness.
>One difference is that a license is required to practice civil engineering
The world would be a better place if developers (or the company they work for) were as much on the hook for bugs in software as en engineer is for a bug in a bridge. How programming can still be the wild west in 2020 is beyond me. I've read some good thoughts about this topic by Poul-Henning Kamp (Varnish, FreeBSD) but can't seem to find it at the moment.
>Most web developers, on the other hand, require large tools to do theirs jobs for them and recoil in irrational fear and disgust when standard DOM methods are used
I would recoil in disgust if I saw a civil engineer building a suspension bridge by hand as well.
As someone who has worked in both worlds, it is just a different sort of nonsense that you have to deal with. Typically the physical engineering thing is "we want you to work out why this weird thing is happening, then fix it, without us having to change anything operationally or spend any money." just a different flavor of the same crap.
> I often hear people say that software engineering is a joke compared to civil engineering ...
I think your example points out exactly why some think software engineering is a joke: they rush ass first to implement something (and they implement the wrong thing) instead of sitting down and figuring out the actual requirements first like any real engineering job would have you do.
And it looks like everyone is pushing it more into this ass-first direction with agile. Let's not even try to plan ahead! You know what you want next week, so this short-sighted focus leads to chaotic development and once the real requirements are figured out 9 months into the project, well too bad it's too late to redesign and rewrite it all properly. So it's forever going to be a bumpy and crooked bridge on the verge of collapse, held together by more and more duck tape, hot glue and occult ceremony. And there's a plastic tunnel hanging underneath it. Only the brave will crawl through.
> instead of sitting down and figuring out the actual requirements first like any real engineering job
If it were so easy, then we would have done it already that way for the last seven decades. The simile topples over upon further contemplation:
civil engineers:
• client is not a domain expert
• to an overwhelming part, client needs are easy to transport into the mind of c.eng.
• can employ a wealth of standard solutions refined over the course of milleniums
software authors:
• client is a domain expert for the subject matter that the software is supposed to model
• to an overwhelming part, client needs are difficult to express and transport into the mind of s.auth.
• if a standard solution exists, the client would have already bought it off the shelf, so coming to a s.auth. always means customised development
• the entire sector is still in its proverbial baby shoes
We have to come to grips that we unfortunately can't apply what happens to work well for a different sector. The supposed value of non-traditional software methodology lies in that at least the client notices that the requirements are off the needs rather early.
> figuring out the actual requirements first like any real engineering job would have you do
There are no "actual" requirements for most software projects. Software is generally co-evolved with the audience.
Bridge designers can work like they do because bridges are hard to change and fundamentally pretty similar. But because software infinitely changeable and infinitely copyable, our field is different. If you're going to build 500 highway overpass bridges, you'll need engineers looking at each one, because local conditions and needs vary. But in software if we need to serve 500 users, we build one product, give each user a copy, and just keep adding features to solve the local problems.
A big reason we think software can be like bridges is that in the early history of our profession, we were tackling problems that almost worked in a waterfall context. That's because we were taking existing paper processes and automating them. But the hard part of requirements discovery via process coevolution had been done for us by people tinkering with paper and human working relationships.
That era is past. Today if the requirements for something are perfectly knowable, that's because it's either trivial or it's copying an existing piece of software. Any real product is discovering what's possible. It's growing along with its users' needs. It's solving new problems created by other people and groups.
I know of no significant piece of software that, like a bridge, hit 1.0 and just stayed there for a decade while getting plenty of use because the requirements were perfectly foreseen. Not one. To me that's a sign that perfect foreknowledge is, if not impossible, at least incredibly rare. So I think the thing to do is to figure out how to build excellent software with the expectation that needs will change.
Thats because we have tried it the other way. Its called waterfall. The problem is, the process is too slow in such a fast moving industry.
If you are building a bridge, you dont have the problem of being half way done and all your customers say, "nah, nvm there is tunnel that just went up, that can kind of solve my needs. I will use that one instead."
A large part of the problem is that grand majority of software (at least if it's facing actual human clients) is constantly trying to search or validate market-fit. If you don't get it out first, you're going to lose to a competitor who does.
And even when you do have a solid market-fit figured out, you still don't know what your customers will actually want. (And don't get me started on customer research. People lie all the time, and their accuracy on what features are honest-to-$deity blockers.. Nope.) This means that for most parts the incentives are misaligned and work actively against delivering high-quality software.
Underlying the agile manifesto is the need for engineering to be properly aligned with business incentives. Continuous delivery, fast iteration cycles, incremental improvements and rapid deployments are all facets of the same fact: you don't actually know what your customers want (because your customers don't know what they want!), and the only true way to figure it out is to iterate as fast as you can.
It's only when you have an established moat and a practically guaranteed, net-profitable income stream, when you can even imagine at having the opportunity of doing things the way you would assume you want to.
Oddly enough.. the companies who have such moats and guaranteed profits tend to be the same ones that have been the slowest to modernise themselves. Banks - until the modern online-only challengers came along. Insurance, where the regulatory moats are even higher and is only now being "disrupted". Loan brokering. Energy. Water. Public transport (where monopolies and/or charters prevent competition). Healthcare. On and on and on...
And even then, every one of these established, guaranteed-profit machines has the same problems: the moment one good new player enters the field and starts stealing customers, the old guard needs to find a way to either adapt - which is the best-case scenario - or rely on their power structures with politicians and quickly require new regulations to strangle the usurpers.
Software is expensive to make. It's only cheap to deliver. And time spent making the wrong thing is really expensive.
EDIT: I forgot to say this the first time around. Engineering career incentives are also misaligned. Maintenance is not appreciated, only shipping new stuff is. So the developers who would want to improve what exists and make it better will be looked down upon. The promotions and raises go to those who ship something new, even if it ends up setting the world on fire a year later.
The problem is that you cannot figure out the actual requirements. In every non-trivial application project I had so far, the requirements (and there were lots of them) were simply not correct. The requirements the actual users created, that is. They _think_ they know the workflow. They don’t.
If you don’t even ask the users, it’s even worse.
But that’s okay. It is simply not possible to accurately judge how something will work until you get to use it. That goes for the creators, too. That’s why we iterate.
Having worked on government projects, agile is definitely better than waterfall. The specs will change, better accept that early on and work with it, instead of trying to nail down the wrong thing.
Manager and Director are the people who are pushing "agile". They want quick results, and SE can only do what they want. You simply really can't "gather" requirement and finish a feature and do proper testing in a 2-week sprint.
I do agree there are a lot of bad practices in SE as well, but let's not blame everything on them.
People built a lot of ugly, useless, dangerous bridges before it was possible to plan and build a good one reliably. Even then, bridges still open with huge flaws. I think software engineering will get there eventually. Someone has to beat their head against the unknown a few times to map out its form.
I think it is possible to convert a bridge into a tunnel, to follow with your extreme example.
It's totally possible. The only thing is that when the cost estimation arrives to the hands of decision makers, they open their eyes wide and decide that for that money they better go ahead with a bridge.
So IMHO it's just a matter of cost. Say you go with a bridge but there are some initial wooden stairs, and sometime along the middle of placing them they decide it is acceptable to pay the cost of stopping and replacing them with metallic ones. Could happen.
Biggest change I experienced in the rate of unexpected last-time feature changes in software, was having a project manager that first of all knew how to say "No" (or discuss the sense of the requests), and secondly, was able to communicate the real cost that each change would have (in terms of developer time, which at the end of the day means money). Then it would be the company's boss himself who would decide to discard the most crazy changes that were "mandatory" and coming from the sales people.
And software engineers don't have to deal with half their tensile bolts having 90% of the tensile strength built they don't know which half, or the bridge collapsing because they mixed brass and zinc bolts[1], or hurricanes...
Turns out that every field of engineering is hard!
So much this. I want a civil engineer try and build a bridge over 6 tectonic plates with pretty much all physical constants constantly changing. That would be the equivalent of working with an ever moving tech stack.
Even the language and best practise change constantly. Looking at possibly the most stable language C, we have entirely different best practise pattern from community to community.
Also a civil engineer usually understands exactly what the bridge is supposed to do and how it is going to be used.
In a large corporation, the software engineer expects to be told that there are going to be cars on this bridge, and they are moving at a certain speed from one side to the other and that they will be of a weight between x and y, etc...
Understanding the domain goes a long way to get software done.
Sometimes, that happens. But there's a mutual agreement that such change comes with significant cost, and it's this part that is missing in the software world.
The first step in civil engineering is getting data including hydraulic, geo, and traffic data. Deciding between a bridge and a culvert is part of the design process.
It's not that software engineering is a joke it's that you don't understand the difference between computer work and moving earth/pouring ckncrete. Of course people are going to plan the project differently in civil engineering. The consequences to building any part of a bridge wrong are pretty dire and redoing work costs much more than it did initially.
Maybe don't try to draw parallels with other forms of engineering just because it has the same name in university. The practical differences are large.
I think there is more to it than process. I'm not an engineer, but I know in the US you usually have to pass the PE exam to be a real certified engineer, plus there is the reality that if your bridge collapses, you are liable, might go to jail, etc. I'm unaware of any similar licensing process in software engineering or liability realities. Even when software kills people, it is usually not prosecuted and the devs are not held to the same standards as licensed engineers. For this reason, I just tell people I'm a dev, not an engineer.
I hope this myth would die. Most engineers don’t ever take a PE exam.
The PE exam is only needed for a handful of disciplines, like civil and HVAC engineering. Even then, you only need the PE certification if you are going to be signing legal documents. You can be a civil engineer without a PE working in a team producing designs and plans that are signed by a single certified PE.
By your logic almost no one that graduated from an engineering discipline would ever be able to call themselves engineer.
Also, physical engineering is constrained by a set of available materials, technologies, and physics. In software you could build a pretty accurate simulation of an entire bridge, generalize it so that it can represent all possible bridges, model new materials, and rewrite the rules of physics, the complexity space is infinite.
I think that the engineering mindset (adherence to the scientific method, evidence based decisions, planning for the future etc..) is one that is definitely shared by both groups at least.
But you can absolutely get away with building software without proper engineering standards. It's not so easy to build bridges that way.
> 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.
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
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.
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.
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.
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?
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.
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.
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.
We had some good requirements people. Really good. They didn't just write things down. There was a lot of examination and analysis and plotting and so on, and they were good at it. They'd all begun their careers as software engineers and gradually specialised into being really good at requirements.
I think having all reqs upfront is a utopia that will not happen.
What can I say? It happened to me. Only with one company in seven or so worked for so far. I would not be surprised if people worked two dozen jobs and never experienced it.
You do need high-quality customers, though, and they are hard to come by. I've worked for a company that has turned down customers on the grounds that the potential customer just isn't good enough; they worded it differently, but that's what it was.
The fact that you immediately had questions of the requirements means they were not properly thought out and/or not well-defined (regardless of how many years they spent in the planning/gathering stage). Both of those (well defined, thought-out requirements), along with reasonable people evaluating them, would have yielded a much better outcome overall.
Just like spaghetti programming, you get spaghetti requirements analysis & process-engineering. And even then, they hardly consider some of the things that developers do.
Almost as if the developers that encode the rules in a "hard format" such as a program/system need to be the ones dictating the processes/requirements. I would definitely see that as separate to "reqs and scope done in conjunction with devs developing them".
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.
"Take a government contract I worked on years ago. It is undoubtedly the most successful project I’ve ever worked on, at least from the standpoint of the usual project management metrics: it was completed early, it was completed under budget, and it completed a scheduled month-long acceptance test in three days.
This project operated under some unusual constraints: the contract was denominated and paid in a foreign currency and was absolutely firm fixed-price, with no change management process in the contract at all. In fact, as part of the contract, the acceptance test was laid out as a series of observable, do-this and this-follows tests that could be checked off, yes or no, with very little room for dispute. Because of the terms of the contract, all the risk of any variation in requirements or in foreign exchange rates were on my company.
The process was absolutely, firmly, the classical waterfall, and we proceeded through the steps with confidence, until the final system was completed, delivered, and the acceptance test was, well, accepted.
After which I spend another 18 months with the system, modifying it until it actually satisfied the customers needs.
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.
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.
100% agree. I realised many years ago that to try to restrict/fix requirements was futile - or, you can try, but to what end. It’s like swimming upstream.
The hard part is that being adaptive to change increases the complexity exponentially with size (of project, of people, etc...).
Therefore the only way out of this formula is to reduce ‘size’, and iterate with (/alongside) the customer (even if that is an internal _customer_).
Yes, it's indeed a property, not a problem. The problem is the accidental complexity which has the tendency to increase and requires constant effort/energy from us to keep it low.
Readit News
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.
But any ESL student can tell you the order is quantity, opinion, size, age, shape, color, origin, material, purpose. We'd had to reverse-engineer the rules, and then teach it to newcomers.
There is human behavior and human beings' mental models of that behavior.
Your advice generalizes: As an engineer or scientist, never trust the models. At least not wholesale. They're simplified and inadequate, and the inadequacy is invisible to those using them.
> We wish we could tell you that there’s a predictable pattern here—that certain types of adjectives can always be complemented by both participles and infinitives, while other types are always restricted to one or the other.
> Unfortunately, no clear pattern emerges. Different adjectives simply act differently in different contexts.
In other words, sometimes there isn’t a rule, even after intensive analysis. There’s just a bunch of individual one-off decisions that each happen to work to solve their problem, without representing a coherent policy.
I totally get what you're saying here and in an ideal world, this would be it.
Unfortunately, we don't live in that world, projects have budgets and need to be delivered within a given interval.
They touch other aspects of the business and are interlinked with marketing, support, legal, financing and so on.
I think it's our job as software engineers to figure out the requirements. One issue we have in our industry is that we do a sub par job of educating people regarding how software works and giving them alternatives instead of binary yes/no answers.
I would say most developers (and I'm generalizing here) lack the communication/social skills to do so.
The key here is to strike a balance between features, budgets and deliverables.
Unfortunately, there is such software development platform in which software can be 'sculpted' as if it was a statue, with the client being able to oversee what the software would do at every moment.
In practical terms, here is how software development should go:
1) open an empty canvas (for example in your browser). 2) ask the client what they want. They will say, for example, they want to see a bunch of posts and comments below them. 3) create a list of posts, on the spot. 4) create the ability to add comments below each spot. 5) ask the client 'is this ok?' 6) he/she may say no, so delete the above and restart. 7) otherwise, proceed with the next question 'what else do you want?'.
In the back end, the development mechanism shall create the databases and code needed to handle the tasks in the front end.
After all, the only 4 things we want a computer to do are these: create/search/modify/delete information.
This was before heat map software and click tracking which can do a great job of augmenting customer feedback.
The key part that we found out is that if you take this approach, you have to couple it with high quality software support. We hired and trained folks who knew the entirety of our business and tech (Linux, DNS, HTTP, hosting, etc). Our tech support reps were paid much more highly than others in the industry but it gave us more benefits than just being able to support customers when beta software was ship to prod, it also gave us a training ground for future software engineers, QA folks, SysAdmins, and Product Managers.
What I think a lot of people forget is that software is one piece of the puzzle in solving a problem, it’s absolutely not the whole solution. If you design a process based around connecting with customers on a regular basis and having feedback flow throughout your company, you won’t have to “make perfect features”.
I’ve only worked with a small number of companies since that have understood this. Most I’ve worked with have created communication silos and sit in rooms trying to dream up the perfect set of requirements.
The "build it and they will come" hints at that; it's saying that if you build something, people will see the value and then convince themselves they needed it all along.
One difference is that a license is required to practice civil engineering. Most web developers, on the other hand, require large tools to do theirs jobs for them and recoil in irrational fear and disgust when standard DOM methods are used. I still have people argue with me that the DOM is slow even though all the evidence and browser vendors claim updates to the DOM is simply switching a bit in memory. In other words many web developers have utterly no idea how their platform works.
Another difference is that many developers cannot write. Everything about a bridge is planned in extreme detail before work on the ground ever starts. This level of planning is absent in software. Documentation is also largely absent. In most cases everything is an ad hoc mess. In any other industry this would be a cause of numerous lawsuits.
Another difference is that construction is treated as a business project with a dedicated project manager and project budget. Most business software, on the other hand, is treated as an operation. If you cannot discern the difference between a project (temporary) and an operation (living) your software will never be released as a product to a specified level of quality by a specific date.
However when I got into more creative development I found myself faced with unique problems to which the solution was unknown. The development process in this case is less like an implementation and more a exploration of the problem space.
This process is more like sculpting or writing a book or solving a puzzle. As you sculpt the next steps reveal themselves. As you write a story the plot emerges. In order to solve a puzzle box you probe the box.
Solving the unknown in bridge building is working through sets of equations and to solve for variables. It involves doing math.
Solving the unknown in software involves a similar working through. "Doing the math" for code involves executing code. It's faster and easier. Ignoring this is like restricting your bridge planning by avoiding CAD or doing the math by hand.
Yes, once a solution is mapped out the ideal would be a full rewrite. The benefit of software is that it can be modified and finalized directly like baking a sculpt or revising a manuscript.
If a button allowed the working schematic of your bridge to magically materialize, and changing the schematic affected the real world bridge instantly with negligible implementation cost then civil engineering would evolve in the direction of software development. It's not the other way around.
I've often wondered about this. Who exactly has to be licensed? Are there management layers in civil engineering firms where the license isn't required? I think my point is pretty easy to follow. I'd love for all of us to be licensed to practice software engineering, but I don't hold any hope that it would fix all of the other compounding problems that our industry has as it relates to product/project management and management-born issues.
For example, would being licensed stop executives at a triple-A video game company from prematurely announcing games / release dates, or accepting pre-orders for games that won't be finished on time, and forcing all of the people under then to scramble and crunch and do things that would generally be considered anti-thetical to whatever being licensed in software engineering could mean?
I never really thought about that. There is so much truth to it and why so much Saas is a never ending feature factory! I assume Basecamp thinks of their Saas as a project and that's how they are able to escape the never ending Big Ball of Mud software craziness.
The world would be a better place if developers (or the company they work for) were as much on the hook for bugs in software as en engineer is for a bug in a bridge. How programming can still be the wild west in 2020 is beyond me. I've read some good thoughts about this topic by Poul-Henning Kamp (Varnish, FreeBSD) but can't seem to find it at the moment.
I would recoil in disgust if I saw a civil engineer building a suspension bridge by hand as well.
I think your example points out exactly why some think software engineering is a joke: they rush ass first to implement something (and they implement the wrong thing) instead of sitting down and figuring out the actual requirements first like any real engineering job would have you do.
And it looks like everyone is pushing it more into this ass-first direction with agile. Let's not even try to plan ahead! You know what you want next week, so this short-sighted focus leads to chaotic development and once the real requirements are figured out 9 months into the project, well too bad it's too late to redesign and rewrite it all properly. So it's forever going to be a bumpy and crooked bridge on the verge of collapse, held together by more and more duck tape, hot glue and occult ceremony. And there's a plastic tunnel hanging underneath it. Only the brave will crawl through.
If it were so easy, then we would have done it already that way for the last seven decades. The simile topples over upon further contemplation:
civil engineers:
• client is not a domain expert
• to an overwhelming part, client needs are easy to transport into the mind of c.eng.
• can employ a wealth of standard solutions refined over the course of milleniums
software authors:
• client is a domain expert for the subject matter that the software is supposed to model
• to an overwhelming part, client needs are difficult to express and transport into the mind of s.auth.
• if a standard solution exists, the client would have already bought it off the shelf, so coming to a s.auth. always means customised development
• the entire sector is still in its proverbial baby shoes
We have to come to grips that we unfortunately can't apply what happens to work well for a different sector. The supposed value of non-traditional software methodology lies in that at least the client notices that the requirements are off the needs rather early.
There are no "actual" requirements for most software projects. Software is generally co-evolved with the audience.
Bridge designers can work like they do because bridges are hard to change and fundamentally pretty similar. But because software infinitely changeable and infinitely copyable, our field is different. If you're going to build 500 highway overpass bridges, you'll need engineers looking at each one, because local conditions and needs vary. But in software if we need to serve 500 users, we build one product, give each user a copy, and just keep adding features to solve the local problems.
A big reason we think software can be like bridges is that in the early history of our profession, we were tackling problems that almost worked in a waterfall context. That's because we were taking existing paper processes and automating them. But the hard part of requirements discovery via process coevolution had been done for us by people tinkering with paper and human working relationships.
That era is past. Today if the requirements for something are perfectly knowable, that's because it's either trivial or it's copying an existing piece of software. Any real product is discovering what's possible. It's growing along with its users' needs. It's solving new problems created by other people and groups.
I know of no significant piece of software that, like a bridge, hit 1.0 and just stayed there for a decade while getting plenty of use because the requirements were perfectly foreseen. Not one. To me that's a sign that perfect foreknowledge is, if not impossible, at least incredibly rare. So I think the thing to do is to figure out how to build excellent software with the expectation that needs will change.
Because it's not about bridges or tunnels, common sense is thrown out of the window, people start building something they conjure out of thin air.
Few people say 'No!', we don't do anything. Anything. Until we have written a clear business case / usecase, a raison d'être for this project.
Agile is often abused to not think, not design and just follow the whims of the customer. Nice for billable hours, but long term?
Do you produce anything of value?
And even when you do have a solid market-fit figured out, you still don't know what your customers will actually want. (And don't get me started on customer research. People lie all the time, and their accuracy on what features are honest-to-$deity blockers.. Nope.) This means that for most parts the incentives are misaligned and work actively against delivering high-quality software.
Underlying the agile manifesto is the need for engineering to be properly aligned with business incentives. Continuous delivery, fast iteration cycles, incremental improvements and rapid deployments are all facets of the same fact: you don't actually know what your customers want (because your customers don't know what they want!), and the only true way to figure it out is to iterate as fast as you can.
It's only when you have an established moat and a practically guaranteed, net-profitable income stream, when you can even imagine at having the opportunity of doing things the way you would assume you want to.
Oddly enough.. the companies who have such moats and guaranteed profits tend to be the same ones that have been the slowest to modernise themselves. Banks - until the modern online-only challengers came along. Insurance, where the regulatory moats are even higher and is only now being "disrupted". Loan brokering. Energy. Water. Public transport (where monopolies and/or charters prevent competition). Healthcare. On and on and on...
And even then, every one of these established, guaranteed-profit machines has the same problems: the moment one good new player enters the field and starts stealing customers, the old guard needs to find a way to either adapt - which is the best-case scenario - or rely on their power structures with politicians and quickly require new regulations to strangle the usurpers.
Software is expensive to make. It's only cheap to deliver. And time spent making the wrong thing is really expensive.
EDIT: I forgot to say this the first time around. Engineering career incentives are also misaligned. Maintenance is not appreciated, only shipping new stuff is. So the developers who would want to improve what exists and make it better will be looked down upon. The promotions and raises go to those who ship something new, even if it ends up setting the world on fire a year later.
If you don’t even ask the users, it’s even worse.
But that’s okay. It is simply not possible to accurately judge how something will work until you get to use it. That goes for the creators, too. That’s why we iterate.
I do agree there are a lot of bad practices in SE as well, but let's not blame everything on them.
It's totally possible. The only thing is that when the cost estimation arrives to the hands of decision makers, they open their eyes wide and decide that for that money they better go ahead with a bridge.
So IMHO it's just a matter of cost. Say you go with a bridge but there are some initial wooden stairs, and sometime along the middle of placing them they decide it is acceptable to pay the cost of stopping and replacing them with metallic ones. Could happen.
Biggest change I experienced in the rate of unexpected last-time feature changes in software, was having a project manager that first of all knew how to say "No" (or discuss the sense of the requests), and secondly, was able to communicate the real cost that each change would have (in terms of developer time, which at the end of the day means money). Then it would be the company's boss himself who would decide to discard the most crazy changes that were "mandatory" and coming from the sales people.
Turns out that every field of engineering is hard!
[1]: https://www.fastenal.com/en/70/corrosion
Even the language and best practise change constantly. Looking at possibly the most stable language C, we have entirely different best practise pattern from community to community.
Or where it should be exactly: "It should be easy to move once it is build, right?"
Or what type of vehicles it should handle: "Just build a generic bridge. How difficult can it be."
But the time and monetary budget was already negotiated and written in stone: "Oh btw, you got 2 weeks and $537.25 to finish the bridge."
In a large corporation, the software engineer expects to be told that there are going to be cars on this bridge, and they are moving at a certain speed from one side to the other and that they will be of a weight between x and y, etc...
Understanding the domain goes a long way to get software done.
It's not that software engineering is a joke it's that you don't understand the difference between computer work and moving earth/pouring ckncrete. Of course people are going to plan the project differently in civil engineering. The consequences to building any part of a bridge wrong are pretty dire and redoing work costs much more than it did initially.
Maybe don't try to draw parallels with other forms of engineering just because it has the same name in university. The practical differences are large.
The PE exam is only needed for a handful of disciplines, like civil and HVAC engineering. Even then, you only need the PE certification if you are going to be signing legal documents. You can be a civil engineer without a PE working in a team producing designs and plans that are signed by a single certified PE.
By your logic almost no one that graduated from an engineering discipline would ever be able to call themselves engineer.
I think that the engineering mindset (adherence to the scientific method, evidence based decisions, planning for the future etc..) is one that is definitely shared by both groups at least.
But you can absolutely get away with building software without proper engineering standards. It's not so easy to build bridges that way.
I’ve always thought it is a little bit of a stretch.
Dead Comment
> 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.
> “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.
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.
https://vimeo.com/108441214
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.
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.
I think having all reqs upfront is a utopia that will not happen.
What can I say? It happened to me. Only with one company in seven or so worked for so far. I would not be surprised if people worked two dozen jobs and never experienced it.
You do need high-quality customers, though, and they are hard to come by. I've worked for a company that has turned down customers on the grounds that the potential customer just isn't good enough; they worded it differently, but that's what it was.
Just like spaghetti programming, you get spaghetti requirements analysis & process-engineering. And even then, they hardly consider some of the things that developers do.
Almost as if the developers that encode the rules in a "hard format" such as a program/system need to be the ones dictating the processes/requirements. I would definitely see that as separate to "reqs and scope done in conjunction with devs developing them".
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.
And it's hard do do a proper waterfall when you hardly have an idea of how to even approach the problem.
This project operated under some unusual constraints: the contract was denominated and paid in a foreign currency and was absolutely firm fixed-price, with no change management process in the contract at all. In fact, as part of the contract, the acceptance test was laid out as a series of observable, do-this and this-follows tests that could be checked off, yes or no, with very little room for dispute. Because of the terms of the contract, all the risk of any variation in requirements or in foreign exchange rates were on my company.
The process was absolutely, firmly, the classical waterfall, and we proceeded through the steps with confidence, until the final system was completed, delivered, and the acceptance test was, well, accepted.
After which I spend another 18 months with the system, modifying it until it actually satisfied the customers needs.
"Many times I had a clean elegant abstraction break with a change in requirements.
The hard part is that being adaptive to change increases the complexity exponentially with size (of project, of people, etc...).
Therefore the only way out of this formula is to reduce ‘size’, and iterate with (/alongside) the customer (even if that is an internal _customer_).
It is basic math(s).
Deleted Comment