6 ms·
Self made ... by both the banks and the programmers. As the article notes, these developers don't seem to have done a great job of documentation. Perhaps delib
by repolfx 8y ago
Self made ... by both the banks and the programmers.
As the article notes, these developers don't seem to have done a great job of documentation. Perhaps deliberately, given the comment about personal vindication. "You can't survive without me" is not a great look for either employee or employer.
Perhaps they are cowboy developers in more ways than one.
- Ensorceled 8y agoRight. Those developers who were given days and months to document their work deliberately did nothing instead. Wait, no, I've literally NEVER heard of management asking developers to delay the next release to document their work.
- bitwize 8y agoCouldn't they just find the time to document while they're developing? Oh, but they can't increase the estimate. The customer signed off on that estimate, so we're committed to deliver by that deadline.
- bigmanwalter 8y agoNot really. Code needs to solidify before you document it. Documentation is best saved for after a major release.
- Ensorceled 8y agoExactly. I'm always surprised when people think that it's easy to find time for documentation and that you only skipped that step because you are lazy and/or unprofessional.
- repolfx 8y agoHonestly, I know that's the conventional wisdom, but I've never once heard an engineer go to their manager and say, "I'd like to spend some time documenting this important process you asked me to implement" and being told "no, we don't have time to document! just keep it all in your head!" I'm sure this literally never happens. What I do see quite frequently is developers who don't like writing documentation finding ways to not do it or justify doing a poor job.
- arethuza 8y agoOnly time I've encountered a desperate fixation by a CIO on documenting applications was when the relevant development team was about to be laid off. Fortunately I had already resigned at that point.
- vetinari 8y agoIf you want to blame someone, you can always say that he didn't document his stuff enough. The problem is, that there is no standard, what's "enough", so it is easy to move the goal posts. Combine that with fast paced environment and putting out fires constantly, and you have a recipe for disaster.
- lawlessone 8y ago>If you want to blame someone, you can always say that he didn't document his stuff enough. This, he could have documented it perfectly well in a time when everyone knew COBOL. But that documentation would all be useless to me today with my knowledge of Java and Kotlin, but understandable to someone else from is generation that works with COBOL.
- setr 8y agoTbf, it only really makes sense for the individual programmer to properly document code if there’s a decent chance they’ll forget (eg some obscure part of the codebase), or if you expect a reasonable chance that someone will have to read the code without you. Otherwise, its useful, but not necessary: you just go to the guru (perhaps yourself); his living body is the documentation. If you’re thinking that only you’ll ever read it, or you’ll be working on this codebase for the next 30 years, it doesn’t really matter. Peoper Documentation is a cultural activity required for teams, especially those with shifting workers, as is common now. And should really be enforced by the managers, not the programmers thenselves. Its significantly less necessary when you can expect to spend most of your career on a single codebase, a workstyle these cobol programmers presumably came from.
- TomMarius 8y agoWhat happens when a bus hits the guru?
- zoggenhoff 8y agoGuru meditation error.
- sekh60 8y agoYour DR planning better include a necromancer.
- llcoolv 8y agoyeah. this is how it had been done before the invention of writing. time has proven it not to be a very efficient method.
- tcbawo 8y agoI try to design and name interfaces clearly and comment code for myself. If it's been a few weeks since I've looked at something it helps me snap back. Also, I would never approach a codebase as if I will be working on it for 30 years. Job security comes from marketability, not obscurity.
- oldandtired 8y agoYou, obviously, have no idea how hard it is to write decent documentation for any system. Especially when it has been in existence for many years. Good documentation is hard and anyone who thinks it is not does not have a clue as to what is needed for the purposes of maintaining any piece of software. It is a very rare event to see documentation of a quality that explains all the interrelationships, reasons for the choice, etc, etc, etc. I have in the past been required to provide all the documentation for projects I have worked on, functional and technical specifications, user guides and cheat sheets, detailed design documents and all of these take considerable time to write well. I can't say I am expert in this area because I am not. But I have done a lot better than most of the projects that I have had to interface to over the decades. Documentation is a low priority for many management teams, they do not see the use in the kind of details that are needed. They do not give it sufficient support to do the job well. I have seen and worked with people who have the skill to write the kind of documentation that is actually needed and they are a rare breed, well worth any money you pay them. When companies complain about "cowboys", they often do not see that it is they who are the "cowboys".
- repolfx 8y agoYou, obviously, have no idea how hard it is to write decent documentation for any system. Especially when it has been in existence for many years. I've been programming for decades and my current project is frequently praised by other developers who work with it (it's a framework) for the quality of its documentation. So, in fact, I do have such an idea. It's hard work. We do it anyway because we're professionals. The fact that people frequently don't do it doesn't change this. One technique I use is to keep documentation in the same repository as the code, and force people to write docs via the code review process. That is, a proposed change doesn't pass review until it also updates the documentation files. People want to get their code merged, so they know they'll have to take docs seriously or else it'll get picked up in review. Now maybe back in the mainframe days there was no culture of code review, but these are banks we're talking about. They excel at process. So it seems kind of unlikely they'd not want things documented, if management had understood what needed to be documented in the first place. But ultimately it was only the employees who knew that.
- sharemywin 8y agoHow many new devs are willing to even touch a COBOL program. documentation or not.
- ams6110 8y agoFor enough money, I'd say many. COBOL isn't sexy, but it's not difficult either. And it's demonstrated a lot more staying power than most other languages.
- diggernet 8y agoDarn right! I'd cheerfully learn Cobol for a job with the right parameters. I once took an RPG course in order to apply for one (though sadly did not get it).
- toast0 8y agoThe only way to have really quality documentation is to have a lot of people reading it and providing feedback, over time. It also doesn't hurt when a quality technical writer actually writes or edits the documentation in consultation with the people who designed or implemented the system.