41–50 of 251 posts
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.
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.
Agile is about giving developers the illusion of control, so they are more comfortable committing to an endless cycle of nonsense.
That’s a really interesting perspective. I’m doing a waterfall on my current project and it just feels more right
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.
> “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 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?".
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 Transcript: https://github.com/matthiasn/talk-transcripts/blob/master/Hi...
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?".
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?".
I often hear people use that logic as a reason why software doesn't qualify as engineering
I’ve always thought it is a little bit of a stretch.
Earlier quoted context omitted.
I often hear people use that logic as a reason why software doesn't qualify as engineering
Do you share the opinion that software doesn’t qualify as engineering? I’ve always thought it is a little bit of a stretch.
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)