Writing software is hard
-
Good software is uncommon because writing it is hard. In the abstract, we all know that it is hard. We talk incessantly about how it’s hard. And yet, we also collectively seem shocked — just shocked! — when the expectable happens and the software we’re exposed to or is working on turns out poor.
Discuss
Maybe if he didn't write in Rails?
-
Good software is uncommon because writing it is hard. In the abstract, we all know that it is hard. We talk incessantly about how it’s hard. And yet, we also collectively seem shocked — just shocked! — when the expectable happens and the software we’re exposed to or is working on turns out poor.
Discuss
Maybe if he didn't write in Rails?
wrong message reply
-
Good software is uncommon because writing it is hard. In the abstract, we all know that it is hard. We talk incessantly about how it’s hard. And yet, we also collectively seem shocked — just shocked! — when the expectable happens and the software we’re exposed to or is working on turns out poor.
Discuss
Maybe if he didn't write in Rails?
Kent Sharkey wrote:
the software we’re exposed to or is working on turns out poor.
Author should probably proofread at least his first paragraph especially on the topic of pride in your work ;) I do agree that people should stop pretending that it's easy to write good code. I've reviewed code I wrote say, six months ago, and thought "what was I thinking? I can do this better." Part of the never-ending process - learn, adapt, apply. I don't agree that developers blame everyone else for this. I'm very self-critical with my code and many people I know take pride in what they do. Of course this is entirely subjective to personal experiences and YMMV.
-
Good software is uncommon because writing it is hard. In the abstract, we all know that it is hard. We talk incessantly about how it’s hard. And yet, we also collectively seem shocked — just shocked! — when the expectable happens and the software we’re exposed to or is working on turns out poor.
Discuss
Maybe if he didn't write in Rails?
management, client and money are also a cause of he weakness. software is an ease scapegoat. How many times was I told "we got no time, if it works, forget it, that should have been finished last week" And also changing requirement which end up doing something completely different from the original design, with no extra time.
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
-
Good software is uncommon because writing it is hard. In the abstract, we all know that it is hard. We talk incessantly about how it’s hard. And yet, we also collectively seem shocked — just shocked! — when the expectable happens and the software we’re exposed to or is working on turns out poor.
Discuss
Maybe if he didn't write in Rails?
DHH wrote:
If I blame my tools
I blame on requirements not being clear ...
Wonde Tadesse
-
Good software is uncommon because writing it is hard. In the abstract, we all know that it is hard. We talk incessantly about how it’s hard. And yet, we also collectively seem shocked — just shocked! — when the expectable happens and the software we’re exposed to or is working on turns out poor.
Discuss
Maybe if he didn't write in Rails?
Good software is not all that difficult to write. Keeping it good over time is hard especially where the team changes, and the prizes are given to the "new project". We do, however, need to adopt the apprenticeship model to allow junior devs to get up on the first step safely.
-
Good software is uncommon because writing it is hard. In the abstract, we all know that it is hard. We talk incessantly about how it’s hard. And yet, we also collectively seem shocked — just shocked! — when the expectable happens and the software we’re exposed to or is working on turns out poor.
Discuss
Maybe if he didn't write in Rails?
I'd like to add insert the Cage meme that's sarcastic surprised and says: You dont say? But I'm not that surprised when my code turns out poorly written. It usually happens when I leave the slow and steady approach and starts rushing things. Similar if you sit down to write an A4 by hand for some reason. It starts neat and orderly but as ideas build up and patience runs out it kinda dissolves in to the gibberish that's my default hand writing. I pity the poor sod that has to go back and debug my code (future me).
-
Good software is uncommon because writing it is hard. In the abstract, we all know that it is hard. We talk incessantly about how it’s hard. And yet, we also collectively seem shocked — just shocked! — when the expectable happens and the software we’re exposed to or is working on turns out poor.
Discuss
Maybe if he didn't write in Rails?
Yes and no. Yes, it's hard to write highly readable and maintainable code that obviously has no bugs. But I do think that a lot of the code I see is not hard to improve. A lot of people just never get past that "getting started" level of programming. A lot of programmers just landed a job and never learned anything after that. They've got this nice if-else-thingy and now they can write an entire program in a single function using a gazillion if-else branches. Yes, it works and it's probably easy to write initially. Unfortunately, the code still sucks and no one (not even the original author) will be able to update it in the future. Now is it fair to say that "programming is just so hard"? I don't think so, what we should be saying is that far too many people are just a bunch of bunglers who don't like to properly learn their profession because that takes time and effort and they'd rather have a beer and watch television. So, I'm not saying programming is easy, but I do think a lot of bad code is written not because programming is hard, but because the authors are lazy and/or not cut out to be a programmer. Just to illustrate my point, after about three months of programming (starting from scratch) I was able to tell my coworkers (with 10+ years of experience) that they were using try-catch completely wrong. No one, apparently, bothered to look up how try-catch could be used properly. The result was that each and every function had at least one try-catch block that, at best, logged the error and rethrew the exception. Everything was logged many times, but not StackTraces because who can read that stuff anyway... As you can guess, try-catch wasn't the only thing they didn't grasp... At my new job, I could tell a team of five that they were using the Entity Framework completely wrong. They were going at it for four years, but none of those five people had really looked up how everything worked. The result was that their application was really slow and bloated (and none of them knew how to tackle a SQL Server performance problem either). Again, they had more problems than just Entity Framework... Good news for the people who do read an occasional book or article though. It's quite easy to be better than everyone else :)
arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinct
-
Good software is uncommon because writing it is hard. In the abstract, we all know that it is hard. We talk incessantly about how it’s hard. And yet, we also collectively seem shocked — just shocked! — when the expectable happens and the software we’re exposed to or is working on turns out poor.
Discuss
Maybe if he didn't write in Rails?
Maybe because I'm not part of a coding team in the usual sense of the word. Applications are written, often enough for the use of another developer so they can do their thing. They tell me (or I tell them) what I need and then, apart from some tweaks, it's done. Typically, the melded result is in front of the users - and they're made to fit one another. You know it works because you've tested the crap out of it before you hand it off. Could that be because we all feel this stuff "has my name on it" - if you make junk you'll be known for making junk. Pretty much, the preceding sentence says it all. A lot has to do with experience, too. Where do users usually screw up the best of intentions? How do we stop them? How do we leave those 'stubs' for likely expansion? Expand function and feature without breaking the existing? All stuff you learn the hard way . . . . . . and those of us in the business for a while have the scars to prove it.
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein
"If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010
-
Maybe because I'm not part of a coding team in the usual sense of the word. Applications are written, often enough for the use of another developer so they can do their thing. They tell me (or I tell them) what I need and then, apart from some tweaks, it's done. Typically, the melded result is in front of the users - and they're made to fit one another. You know it works because you've tested the crap out of it before you hand it off. Could that be because we all feel this stuff "has my name on it" - if you make junk you'll be known for making junk. Pretty much, the preceding sentence says it all. A lot has to do with experience, too. Where do users usually screw up the best of intentions? How do we stop them? How do we leave those 'stubs' for likely expansion? Expand function and feature without breaking the existing? All stuff you learn the hard way . . . . . . and those of us in the business for a while have the scars to prove it.
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein
"If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010
W∴ Balboos wrote:
A lot has to do with experience, too. Where do users usually screw up the best of intentions? How do we stop them?
:thumbsup: Excellent point and one that I'd like to add to. Anticipating edge cases and use patterns is a talent that one can only acquire from being in the trenches and in most cases understanding your end user's business better than they do. :)
"Go forth into the source" - Neal Morse
-
Good software is uncommon because writing it is hard. In the abstract, we all know that it is hard. We talk incessantly about how it’s hard. And yet, we also collectively seem shocked — just shocked! — when the expectable happens and the software we’re exposed to or is working on turns out poor.
Discuss
Maybe if he didn't write in Rails?
Writing [good] software IS hard, but management thinks it's magic. Put in less snarky terms; writing good software takes time, but management doesn't believe it.
-
Kent Sharkey wrote:
the software we’re exposed to or is working on turns out poor.
Author should probably proofread at least his first paragraph especially on the topic of pride in your work ;) I do agree that people should stop pretending that it's easy to write good code. I've reviewed code I wrote say, six months ago, and thought "what was I thinking? I can do this better." Part of the never-ending process - learn, adapt, apply. I don't agree that developers blame everyone else for this. I'm very self-critical with my code and many people I know take pride in what they do. Of course this is entirely subjective to personal experiences and YMMV.
Writing English is hard.
I wanna be a eunuchs developer! Pass me a bread knife!
