I agree. A startup really doesn't have to build their own credit card processing solution.
WRT PCI DSS it's not very hard to comply. Some 7 years ago in a company that persisted everything about customers we changed the system for compliance within two weeks.
Thanks for that but to be honest it just sound like more of the same, but viewed from a different angle.
My understanding of your write up is that that tests may be written without understanding the problem. I mean that is just dumb TDD religious zealots who would do that sort of thing, assuming that test make up for design (and thought process). I also think that the verification process is an inherent part of waterfall model - hence the iterations.
That was in the MVP (minimum viable product) section. I also referred to an old post of mine, on bad code http://www.mehdi-khalili.com/bad-code, where I explain that in great details. I hope you find that useful.
I guess the reason I didn't do it for BDD was that I have written a lot of posts about Behavior/Test Driven Development and incorrectly assumed that my readers know about that. My mistake. It's fixed now. Thanks.
Like you I love to look at code and IMO that's where OSS (Open Source Software) shines because people contribute to OSS when they feel passionate; so that should be a good indicator. I also get candidates to submit coding puzzles and later get them to change it while I am looking over their shoulders!
RE "I need you to be able to at least do an acceptable job regardless" Until recently I thought I can always write awesome code; but it's not until we're brought down to our knees that we appreciate how personal issues could impact everything in our lives.
Besides some publicity, partly due to key person's popular books/blog I believe, why is ThoughtWorks special? I mean, isn't it just yet another enterprise/CRUD app development shop?
Note that I rather specifically said "acceptable" code. That means "not good, but not terrible". Acceptable can be mediocre. But it shouldn't ever be bad.
You didn't. I'm looking for specific examples of what you consider "mediocre" code. I'd love to be able to understand what you this is to you - given it is so subjective.
Upon thinking about it... I think it's actually what I said to start - neither good nor terrible. Defining good and terrible code is easier than defining mediocre code, so we can do it by process of elimination. Mediocre code isn't terrible, but it's not good code either.
So, what is good code? Testable and well-tested, modular, isolated, easy to read, robust, performant...
What is terrible code? Well, the opposite of that, but generally there are some key indicators - code that breaks badly in edge cases, code that is impossible to read, code that entangles itself in a lot of other code, code that is hard to test.
So, mediocre code would be something that has some of the properties of good code, but is missing a few of the more important ones... maybe the tests aren't fully baked, maybe there are some inefficiencies, maybe it's a little harder to read than it could be, maybe it's not quite as isolated from the rest of the code as one might like.
The difference between mediocre and bad is the number of subpar things and their severity. If there are no tests, that's bad. If the code is horribly entangled with unrelated code, that's bad. If it's N cubed time in a place where we expect to handle large amounts of data, that's bad. If it ignores several common edge cases that will have really bad effects, that's bad.
It is subjective, but it's not entirely opinion, either.
Not at all. The post was published by AddThis and I didn't realize the issue. I am glad it was highlighted so I could fix it sooner than later. Thanks.
WRT PCI DSS it's not very hard to comply. Some 7 years ago in a company that persisted everything about customers we changed the system for compliance within two weeks.