The fact that we’re having these discussions shows to me how immature our industry still is. Say, people figured out pretty well by now how to design, build, maintain and use aircrafts. Not so much spacecrafts, though. Yes, hardware is improving faster than anything, but I wouldn’t say the same about software, unfortunately. I’m still puzzled what CS education does – those graduates seem incapable of doing real coding jobs. And the camps phenomena is a different story all together. As a result, we keep on guessing and experimenting on every project, everywhere. Just imagine the same in the airspace industry (not that they don’t experiment, just in a completely different manner). I don’t know what I’m doing wrong, but it seems everything I built or coded wasn’t great: under-engineered, over-engineered, took too long, used wrong platforms, etc. There are certain minimums below which the software is crap, but we never know what they are, and there are no standards that last long enough, as they lack value and have to be rewritten. The big software companies don’t lead, and they are actively opposed by the general industry public; the Open Source community sounds great, but I think that the Every Man for Himself state of the industry is till predominant. So, lots of things to work on and improve – got to sound positive at the end.
Stop future-proofing software
51–60 of 63 posts
Re: Stop future-proofing software
#52my understanding is that keep code modular, if it repeats 3 times then 'maybe' abstract it, and no matter what you do .. in time you'd have to rewrite from scratch if not all but parts of it.
there is no future proofing as there is no way to predict or time to put effort in predicting how business needs are going to change, how apis you talk are going to change, and how technologies you use are going to change.
it's easier to just write simple functions, that you can come to later and see what they do quickly and change them.
Only on going problem I do have is dependency, that I've to check every thing that used the said function, does it continue to work
Re: Stop future-proofing software
#53Some nobody insisting everyone is doing it wrong.
Re: Stop future-proofing software
#54Earlier quoted context omitted.
I think the real takeaway is that composition is much more likely to model the semantics you have, even though inheritance feels like it gives you better code re-use.
I admit to being a composition bigot when green fielding some functionality, and I've never felt like code reuse was a thing either mattered for. I like composition because it's easier to create small testable component contracts. But I maintain plenty of inheritanace based code and, while it's less testable, it's... fine. Not really a big deal to use either or both. Edit: to be clear, when I hear "code reuse", I thi…
> But I maintain plenty of inheritanace based code and, while it's less testable, it's... fine.
I'd wager that it's rather good code then. There's also the inheritance-based code that isn't though, which slowly is driving me to the conclusion that "unsupervised" inheritance is some sort of petri dish for cthulhu-esque architectures.
That doesn't mean inheritance is bad, per se -- just that we should stop and think much more about using it. Composability, on the other hand, isn't nearly as "invasive" since the whole point of it is the interaction of uncoupled things.
This somehow reminds me of the promise of fusion vs. fission energy, where it's argued that in fusion you don't have to constantly prevent your reactor from exploding... :)
Re: Stop future-proofing software
#55Earlier quoted context omitted.
I think the real takeaway is that composition is much more likely to model the semantics you have, even though inheritance feels like it gives you better code re-use.
I admit to being a composition bigot when green fielding some functionality, and I've never felt like code reuse was a thing either mattered for. I like composition because it's easier to create small testable component contracts. But I maintain plenty of inheritanace based code and, while it's less testable, it's... fine. Not really a big deal to use either or both. Edit: to be clear, when I hear "code reuse", I thi…
I like composition because it's easier to create small testable component contracts.
You don't need testability or 'greenfielding' for this. 'Design by contract', as you mention, is a useful way to think about this, without attaching value judgments to composition or inheritance. Inheritance is a much stronger and therefore burdensome contract. It's much less likely bits of your model can really adhere to it. The advice to lean towards composition is a function of that - few models can meet that high bar.
Re: Stop future-proofing software
#56We built an SQL compiler in Haskell, and this has been our model from day 0 (back in 2010)... It's really easy to follow these rules with Haskell. We develop our syntax to be easily extensible. Being strongly and statically typed allows us to extend our parser/compiler with relative ease, and not think too much about how the future will look.
Any chance to open source and have a look? Thanks!
The parser is open source - https://github.com/JakeWheat/hssqlppp
Re: Stop future-proofing software
#57Re: Stop future-proofing software
#58The simpler your codebase is, the easier it is to adjust to fulfill a different purpose. I think this is the most important sentence in the article. I've worked on a few extremely abstracted and horribly-indirect codebases that happened to be so very flexible and extensible in exactly all the wrong directions, so much that it made it much harder to change in the way that was actually required.
Sometimes they are so abstract that you fail to notice that they are actually extensible in the required direction.
Re: Stop future-proofing software
#59As Martin Fowler correctly explains, YAGNI is primarily about end-user features, not the flexibility of the code and the toolchain. If you don't keep your tech stack (code, infrastructure, people) flexible, then iterative development becomes impossible. The assumption behind YAGNI is that 'you can't predict requirements accurately'. Which is true, so don't build them ahead of time. However, the same assumption requir…
This is a good point. But it only goes so far.
Ultimately, even code and toolchain flexibility comes at a cost - for example, should you go for a non-relational database because of potential future scalability needs, or cross that bridge when you come to it? Or should you make your code internationalizable, even though the first release is in English only? The right answer may depend on the probability of the business need occuring in some foreseeable time frame.
Unfortunately, the OPs point is too black and white, where the reality is much more grey. In my view decisions in a project need to be subject to a cost-benefit trade-off, and future-proofing is no exception.
Re: Stop future-proofing software
#60I don't have a problem with future-proofing. I do have a problem with half-solutions (which is mainly what I see in the industry). E.g. if you need to run some code before or after a transaction, make a generic way to make this happen.
The problem is that devs do not create enough leverage in their solutions, so they're never that useful in the future. And, devs tend to over estimate what is actually re-usable. The second point may be the most important. Too often, I see solutions that are half-way reusable, which means they're not re-usable at all.
In the end, building out a solid foundation is key. The problem is, this is pretty hard and takes a lot of experience to know how to do well.