dachrillz

Hello everyone,

I've sort of come to the conclusion that I prefer writing API-specification (Open API in this case) before starting to write the application itself.

The reason mainly being that if one writes the specification first, one has to think through the api, its error codes an so forth. There is nothing wrong with going the other way, namely generating the specification from the code. However, I have this intuition that there will always be edge cases where you will end up having to manually write parts of the specification anyways.

This means that there is a great risk that the specification drifts from the implementation as the application/specification matures. The reason being is that one has to manually make sure that the specification matches the application, which is bound to be error prone!

My question is basically, how would you approach this problem? Do you know any tools that can help one make sure the specification matches the application? I've looked through some of the "Open API tools" [1], but none of them seem to really fully solve the problem.

Thank you for your time :D

[1] https://openapi.tools/

Hello all,

We recently had a discussion at work about how software decays. That is, if one does not actively work on a piece of software it will eventually fall into ruin. This can happen e.g. because expertise is slowly rotated out of the business, dependencies break or the software can't be run on newer operating systems.

This begged the question: Is there any software that is essentially done? Where the last commit to the code base was done eons ago and where we expect this software to work for the foreseeable future.

The closest thing I can think of is projects that are feature complete. But they still need active patching.

Cheers