Shipped code > Well architected incomplete features.
Your user does not care in the slightest if you're using a design pattern, or if you are using dependancy injection, or if there is 100% code coverage. Just make it work! Then make it faster! Then make it more readable! In that order.
You might ship faster but this can easily lead to poorly written, hard to maintain and insecure spaghetti code. In fact, rushing to ship / meet deadlines is probably responsible for most of the vulnerabilities in software.
Bingo. Do it right the first time. I'd rather take an extra hour on a bit of code the first time then go back and spend 2 hours refactoring it later on.
I guess shipping is more important to you than the possibility of losing user details (or worse). Christ, I hope I never give my details to a company you found.
Shipping quickly is important but it's also important to write quality code. Small bugs that can easily be fixed are fine but security problems or bugs related to payments, for example, are not.
so, maybe, just maybe, you take a bit more time on parts involving security (that is to say, handling of user credientials (includes session management, cookies, etc) and payment related things)?
Companies don't normally fail because of security flaws, in the same way Boeing doesn't go bust when it has to ground 787s. But in both cases you end up potentially taking a huge hit in costs. Off the top of my head, Sony had to write down $170 million in costs when PSN was compromised, and TJ Maxx ended up paying out $800 million in costs, damages, and compensation after their payment terminals leaked credit card details.
These are not figures you want to see on your bottom line.
If your first reaction when someone talks about security flaws in payments is 'will it make my business fail' rather than 'is this going to fuck my customers' you need to re-evaluate your priorities.
This is a straw man, right? Not all bugs are payment security bugs. Not all bugs are harmful to users. And spending more time writing cleaner code does not mean you'll have fewer bugs.
That approach only works in the short-term though. When you've got an already large code-base you just 'made work' but with no tests (code-coverage), how do you 'make it faster' or 'make it readable' without breaking things? Especially as you are likely under pressure to be adding new features.
I'm all for tests but tests aren't the ONLY way to write software that you can modify without "breaking things." It does require more time to develop and test, but then again, you're saving some time by not writing and maintaing tests.
Again, I believe in automated testing because I think it hedges my risk but I'd caution against believing your own hype that there is only one way to do something..
>I'm all for tests but tests aren't the ONLY way to write software that you can modify without "breaking things."
What are some other methodologies that can let me change code with the confidence well-written tests give me? Would love to be able to employ them when automated tests aren't feasible.
I can't speak to your subjective question but there's a lot of software without automated testing that people are completely capable of modifying without breaking. Ask me a real question and not one about the confidence YOU get from something and I'll see if i can't answer it.
I believe there is a rather apt quote by someone whose name escapes me right now (C.J.Hoare maybe?). It goes (paraphrasing):
"There are two ways to write software. One is to write code that contains no obvious deficiencies, and the second is to write code that obviously contains no deficiencies. The second way is much harder"
I always took this as an argument for smaller, composable components that value simplicity over complexity, dumb over smart and composable over monolithic. I personally (not quite there yet!) try to write code in this manner. I find that the more straight forward and simple the code, the less need there is for tests because I can hold the whole of the code base in my head.
Shipped code > Well architected incomplete features.
Actually there is more wisdom hidden in this dogma. I'd argue you can't really well architect anything without iterating running code. So, it's more of a cycle. At least in my case. Proto, use, profile, refactor, proto new stuff into it, use, profile, refactor...
This cycle usually ends too early though, sometimes at the first iteration, and the code will be pushed to production. Usually the spec is lacking and the customer (internal or external) doesn't really know what he wants. After that, feature requests and bug fix hacks will deteriorate the condition of the code base to the point where things break if you look at it. Rewriting will be difficult because instead of formalising the requirements in a specification, with all the hacks and features added the existing code base is the spec. So you end up with something very fragile and not so agile. At the bottom lies a first iteration model which the original developer (who left the company a couple of years ago), have been given some time to reflect on things, now knows to be a model which can't possibly scale.
Sometimes (not always), it's best to release when ready. Shipping is important for a company, but for a dev team/individual it should be further down on the list and more importantly, development is not done after the first release and features don't maintain themselves.
I don't like the whole 'ship as soon as possible'-thing.
Shipped code > Well architected incomplete features.
Your user does not care in the slightest if you're using a design pattern, or if you are using dependancy injection, or if there is 100% code coverage. Just make it work! Then make it faster! Then make it more readable! In that order.