What can be learned from studying long gone development practices?
shape-of-code.coding-guidelines.com
What can be learned from studying long gone development practices?
1–10 of 142 posts
Re: What can be learned from studying long gone development practices?
#2Very shallow article. Tl;dr: none.
I would say that the mythical man month concept has stayed and still is talked about today even though the book itself is also hopelessly outdated except maybe in IBM style enterprise software.
Re: What can be learned from studying long gone development practices?
#3Very shallow article. Tl;dr: none. I would say that the mythical man month concept has stayed and still is talked about today even though the book itself is also hopelessly outdated except maybe in IBM style enterprise software.
stopped reading at "when I wrote my book"
Re: What can be learned from studying long gone development practices?
#4Very shallow article. Tl;dr: none. I would say that the mythical man month concept has stayed and still is talked about today even though the book itself is also hopelessly outdated except maybe in IBM style enterprise software.
> even though the book itself is also hopelessly outdated
What parts did you find dated? I haven't read it in the last few years, but I still get reminded of concepts like Second System Effect every once in a while.
Re: What can be learned from studying long gone development practices?
#5Very shallow article. Tl;dr: none. I would say that the mythical man month concept has stayed and still is talked about today even though the book itself is also hopelessly outdated except maybe in IBM style enterprise software.
It was actually an interesting read.
TLDR: Whatever software building methodology/process you are using now, is probably crap, and made up by people that don't really know any better and just making things on the go.
Eg. He mentioned 'structured programing' was a fad at the time. Now it is Agile, and its offshoots.
Best way to deliver software is to have a handful of capable people and pay them well and get out of their way. The key to get paid well as a dev. is to be in a project that is important, life/death for the company.
I think the most interesting part of the article was the early job divisions while building software. It didn't make sense, but it was adopted due to the coorporate culture of the time.
Re: What can be learned from studying long gone development practices?
#6Very shallow article. Tl;dr: none. I would say that the mythical man month concept has stayed and still is talked about today even though the book itself is also hopelessly outdated except maybe in IBM style enterprise software.
It was actually an interesting read. TLDR: Whatever software building methodology/process you are using now, is probably crap, and made up by people that don't really know any better and just making things on the go. Eg. He mentioned 'structured programing' was a fad at the time. Now it is Agile, and its offshoots. Best way to deliver software is to have a handful of capable people and pay them well and get out of th…
> Best way to deliver software is to have a handful of capable people and pay them well and get out of their way.
That is the gist of one of the essays in The Mythical Man Month mentioned in the parent.
Re: What can be learned from studying long gone development practices?
#7It is possible to produce software of great quality if you are willing to spend a lot of money on it. And if you want to build big system good quality is a necessity. Else you will discover like IBM did early on that fixing one bug on average can create 1.2 new bugs, or something like that.
The issue is that often the quality is good enough to have something that works and then the buyer/payer does not want to spend more. Problem with that is it makes the maintenance and future adaptations expensive and can turn the system into one where fixing one bug creates 1.2 new bugs.
Therefore I think it is wise to err on the side of caution and spend more on software quality than seems to be needed immediately. It is a bit like in the early days of bridge-building the bridges needed to be built stronger than needed because it was not possible to calculate the safety margins accurately.
Re: What can be learned from studying long gone development practices?
#8It is possible to produce software of great quality if you are willing to spend a lot of money on it. And if you want to build big system good quality is a necessity. Else you will discover like IBM did early on that fixing one bug on average can create 1.2 new bugs, or something like that. The issue is that often the quality is good enough to have something that works and then the buyer/payer does not want to spend…
Yes and no. I'm too amazed by a world which longs for so many software developers. I mean do they all know that all that software has to be maintained? That software is one of the most expensive human artifacts today and that software rots like hell?
Re: What can be learned from studying long gone development practices?
#9You'll probably learn more by trying to understand why these practices are long gone.
Re: What can be learned from studying long gone development practices?
#10I'm not sure you can call structured programming a fad!
An awful lot of languages (I'd say all commonly used ones) use if/then/else, do..while, for..next, and so on, but I can't remember the last time I saw a program with a complicated control flow done by gotos.
Such things were common in the 1970s, in fact the first professional program I ever read did it that way, and it took me ages to work out what was going on.
One particularly confusing technique was to goto a computed expression. Leads to all sorts of interesting bugs.
The whole point of structured programming was "Don't do that! You can do everything you want to do with a small set of restricted control structures, and the control flow is much easier to read".
I'd say that idea won so hard that we don't even notice it.