I disagree with the author over software engineering vs problem domain issues. It's not that the author is wrong. It's that he doesn't articulate the role of the software engineering concerns. It isn't about whether to obsess about these. It is about when to.
The ideal is to cycle. Focus on the problem domain. Get something working. Come back, look at the software engineering domain. Obsess about that for a while. Then move on to the next project. The cycle itself means you get to be productive, get to focus on solving real problems, and get a chance to evaluate your code style and experience, improving it along the way too.
I have maintained 200k line Perl programs written by someone who never stopped to ponder anything outside the problem domain. It was a total mess. The program was basically a textbook in how not to program, particularly how not to write Perl. Matt Trout said it was "written by the programmer that Matt's Scripting Archive would have fired for writing bad code."
If you want your software to last, then software engineering has to be an aspect of it. But the author is also right that you can't let this detract from solving the problems at hand. Consequently you have to be able to really focus on learning each side in cycles.
I have maintained 200k line Perl programs written by someone who never stopped to ponder anything outside the problem domain
Ditto, though I think I have a unique element to my story.
I spent a week deleting code I couldn't detect a use for. I nuked nearly 40,000 lines and could not discern a difference in functionality (though, couldn't be certain since I hadn't completed the test suite.)
Writing a test suite for software with no spec and only others' vague recollections of meetings to go on (Agile!) is fun - it basically ends up a regression suite enforcing current broken behaviour.
Perl takes no part of the blame for this, some of the Rails code needs to be seen to be believed - looked like an early PHP tutorial in places.
What was great was, the Perl was full of comments about how much easier it would have been in Ruby/Rails because he never bothered to read the docs on references.
I spent a week deleting code I couldn't detect a use for. I nuked nearly 40,000 lines and could not discern a difference in functionality (though, couldn't be certain since I hadn't completed the test suite.)
I don't think we deleted 20k lines. Probably more like 5k.
However the kicker was when deleting something that seemed harmless enough broke something. In that case, it was a comment. We're not talking about smart comments here. We are talking about comments that are parsed and used by the application at run-time for actual logic :-P.
Oh, and when we added test cases for rounding numbers.... the test cases failed....
Regarding the role of language, I would much rather be maintaining bad Perl code than bad PHP code.....
Comments
I disagree with the author over software engineering vs problem domain issues. It's not that the author is wrong. It's that he doesn't articulate the role of the software engineering concerns. It isn't about whether to obsess about these. It is about when to.
The ideal is to cycle. Focus on the problem domain. Get something working. Come back, look at the software engineering domain. Obsess about that for a while. Then move on to the next project. The cycle itself means you get to be productive, get to focus on solving real problems, and get a chance to evaluate your code style and experience, improving it along the way too.
I have maintained 200k line Perl programs written by someone who never stopped to ponder anything outside the problem domain. It was a total mess. The program was basically a textbook in how not to program, particularly how not to write Perl. Matt Trout said it was "written by the programmer that Matt's Scripting Archive would have fired for writing bad code."
If you want your software to last, then software engineering has to be an aspect of it. But the author is also right that you can't let this detract from solving the problems at hand. Consequently you have to be able to really focus on learning each side in cycles.
Ditto, though I think I have a unique element to my story.
I spent a week deleting code I couldn't detect a use for. I nuked nearly 40,000 lines and could not discern a difference in functionality (though, couldn't be certain since I hadn't completed the test suite.)
Writing a test suite for software with no spec and only others' vague recollections of meetings to go on (Agile!) is fun - it basically ends up a regression suite enforcing current broken behaviour.
Perl takes no part of the blame for this, some of the Rails code needs to be seen to be believed - looked like an early PHP tutorial in places.
What was great was, the Perl was full of comments about how much easier it would have been in Ruby/Rails because he never bothered to read the docs on references.
I don't think we deleted 20k lines. Probably more like 5k.
However the kicker was when deleting something that seemed harmless enough broke something. In that case, it was a comment. We're not talking about smart comments here. We are talking about comments that are parsed and used by the application at run-time for actual logic :-P.
Oh, and when we added test cases for rounding numbers.... the test cases failed....
Regarding the role of language, I would much rather be maintaining bad Perl code than bad PHP code.....