Agile and ISO software standard compliance?
Posted by jamesarthur824248@reddit | ExperiencedDevs | View on Reddit | 11 comments
Hi guys, my company is running a agile style, but recently the management decided to bring in the idea of compliance the ISO standard so to prove our software is more reliable etc etc. up to a point we devs find it very annoying that we have to write a big documentation at the start, and keep updating it as we implement stuff. Our company has created a list of checkboxes that are directly from the standard: things like design characteristics, enabling system, interface etc. We feel like it is annoying and we follow the checklist for the sake of checking the checklist not to let us write better software, and in fact we might be writing poorer software because we spent less time coding. Has anyone had this kind of experience and how do different companies do it?
diablo1128@reddit
So I'm not sure I understand how Agile is a concern of yours as it seems like you have issues being compliant with the ISO standards the company has chosen to follow.
I worked on medical device for years and we followed:
This are big guiding documents that basically spell out, from a quality perspective, how medical devices should be done. It's not a paint by the numbers process, you need compliance people to understand the guidelines and translate that in to a company process. Even then individual contributors have to use the brain.
Company process may say there should be coding standards, a code review process, code coverage, and such things, but software needs to define that further.
I don't know your companies motivations for wanting to follow certain standards, but this is a common from what I've seen. People didn't fight it at places I worked at. They internalized what the process wanted and did the work appropriately to process. These checklist were merely a reminder as to what needed to be done.
Why do you feel like it's annoying? Is it forcing you to do things you would have not done otherwise? Which could be a good or bad thing depending on what it is.
It sound like you just don't want to follow the standards the company has chosen and there is nothing that can convince you otherwise. Maybe it's not enabling to "write better software", because you are fighting the process instead of working with it.
Why are you spending less time coding? If it takes 2 days to code up a task then it takes 2 days. How did the process force you to spend less time?
Now maybe you are not estimating well, but that's not the processes fault. If the overhead of process adds 1 days of work on top of coding then you should be advertising 3 days at minimum and probably more. Remember estimates are suppose to be meeting the definition of done not when you think you will have something working as a first pass on your desk.
jamesarthur824248@reddit (OP)
I’m personally not a very experienced dev, so I’m not used to do a lot of designs before coding, I tend to do them as I code. I think it is annoying because, say, we have a document, and now we do things a little bit different because of refactoring, or new feature requests, we need to change the classes, make new classes, etc. The annoying part is, we now have to go back to the previous document, checkout what’s not in sync with the code, and make them on sync again.
Yes, I mean it’s annoying for me to keep the document in sync. And then whenever we make new changes to the document, we run through a review against the checklist again, and potentially back and forth if the reviewer has more feedback.
I’m saying less time to code because this process of syncing document could take a day or two or longer, depending on how picky the reviewer is, and we could have spent the time do refactoring instead. Especially, the reviewer often is someone that doesn’t code himself
diablo1128@reddit
Design documents should not be detailed regurgitations of what you code is doing. This is wrong and as you have expressed means you have to constantly update them when every change.
Design documents should be describing the over all approach to whatever you are working on and why it's this way. It should talk about things like communications between system A and B will follow a pub-sub model and here is why this was chosen. The why should be what you are optimizing for with this decision and why other reasonable approaches were not taken.
It should talk about things like you choose Postgres as the DB, but the project doesn't require the DB to be ACID compliant. Postgres was chosen because A / B / C as this allows future people to understand the thought process. If a DB migration to something else does come up it also makes it clear that Acid compliance is not a requirement.
jamesarthur824248@reddit (OP)
Thanks, I agree. The problem is our management thinks the same checklist should be applied every time we create a new feature of an existing system, so we have to go through something like design artefacts, design decisions, system breakdown, interface etc etc (from the list) even all we do is to add a new graph for a new feature. Which I don’t think it makes sense. We had to write the calculation process as a system, exporting as another system etc to be able to check the checklist
diablo1128@reddit
I guess I would need to see the actual checklist. Having a checklist that applies to ever story is not bad on it's own. There should always be a baseline of understanding before any code is written.
If you adding in a new API, then having the message defined and agreed upon with the people consuming the API is a good thing. You don't want to code it up and then find out later that's not what they really wanted.
I feel like you are adding all kinds of unneeded detail when it isn't necessary. Nothing you listed above says to me you need detailed class diagrams.
tony_sant@reddit
Thats why you need to gen docs based on your code and write docs inside your code as your code, wo you dont treat docs as a seperate thing, and once you are done, its just one command away to regen the docs and update your respective internal docs
Checkout the doc tools available for your programming language
Nevermind86@reddit
I wonder if the Linux kernel, nginx, curl, GCC, the GNU tool chain and the likes are all ISO certified?
LloydAtkinson@reddit
Sounds like a nightmare of bureaucracy
Key-Philosopher-2528@reddit
My experience is that companies starting out on getting ISO certification tend to go way overboard on design documentation. Having worked at 3 big multinational companies, we did barely any design documentation and instead focused on:
Documenting all our processes.
Documenting that we followed the processes.
Documenting where all the documentation was located.
Keeping metrics on outstanding bugs and security scans was considered way more important than details of code and design.
Unfortunately, you have to get through a few audits before it all becomes clear.
jamesarthur824248@reddit (OP)
Thanks. Yeah I do agree we should be spending more effort on bugs or tech debts etc. The reason I brought up agile is because I’ve seen a lot of agile articles mentioning document should be less or kept light, only if that brings value to us.
false79@reddit
Yes, it is a lot of stuff that most people don't care about. But obtaining ISO certification will be able to generate new leads and open up sales to new markets where the minimum is an ISO certification. If you are involved in both the design and implementation of the software, there is no better person to produce the documentation.
Some shops have business/technical analysts that do a lot of the paperwork heavy lifting while the coders can focus on coding. This may not be the case where you work.