Source control should be your single source of change, and check-ins should cause a chain of events via continuous integration and issue tracking. A checkin should cause a build to kick off if it is successful it should deploy to an integration environment where tests should smoke test it. If it smoke tests it continuous integration should up merge to a test branch, deploy to test and then update the ticket system to update all associated tickets to ready for test. When the tester verify the tickets automation should again up merge to release and automation should release to production on a release schedule. This is a solved problem.
Except for all the costs of maintenance. It always costs more, generally in the way of time.
> With virtualization and continuous integration the cost of doing it correctly is marginal
Until you have to debug while the integration fails.
> This is a solved problem.
Even with unlimited funds, you get a cost of time and communication. There are tickets and tickets and a queue and a release schedule. The optimal path is not as simplistic as you would fantasize.
I'm guessing this is relating to my SQL mishap in the opening lines? You're making assumptions that I was doing something manually in production here, and not that I was executing a script that was buggy or against the wrong machine.
Sure, we could build safeguards against this, but it wasn't something we really considered would happen. Needless to say, we've learned from that one!
As others have said, software is a young field, and in many ways we're still pushing and exploring the boundaries of what's possible with software. All of us are still very much "early adopters" in this nascent technology experiment / revolution. The nature of demand and untapped potential for software systems creates a financial incentive for high-stakes rapid experimentation at the expense of sloppiness (in attitude and in software quality) we've seen for as long as there's been software.
I do think investing a little bit more time up front and using TDD combined with good leadership / experience is ultimately healthy for your product and team, if you can manage it. However, we shouldn't forget that being "cowboys" got us to where we are today, and continue to break open exciting new opportunities for software.
I don't understand this dichotomy. What kind of engineer designs anything for a third party without gathering their requirements?
There are static analysis tools that can identify such problems ... sometimes ... maybe ... depending on the language and frameworks in use. But to deploy such tools you have to know about them to begin with. And most devs can't simply produce such a tool if there isn't one on the market because that's not what they're being paid to do.
Unfortunately, knowhow can't be automated away entirely just yet.
Analysis tools are the wrong approach - that code should be simply impossible if you're typing things correctly, and inadequately typed code should be very obvious in code review.
> And most devs can't simply produce such a tool if there isn't one on the market because that's not what they're being paid to do.
Most devs could write such a thing if the company told them to. The reason "that's not what they're being paid to do" comes down to process.
Most organizations barely have enough of a budget to implement the applications they actually need using already existing infrastructure (frameworks, tools, etc.). Asking these organizations to roll their own infrastructure is like asking ordinary people to run their own water or power utility.
NASA with the Space Shuttle software came pretty close. http://history.nasa.gov/computers/Ch4-5.html
That is unlikely. For computational complexity theory reasons, writing correct software is extremely computationally expensive (regardless of whether or not the language is Turing complete). In fact, it is "the hardest problem in computer science", in the sense that any problem with bounded complexity can be efficiently reduced to software verification. Even verifying finite-state-machines (the simplest computational model) is PSPACE-hard.
What we can do is find many ad hoc ways, each helping to some extent with some kinds of correctness properties.
But enough money and the goal of making it infinitely flexible, having all the possible features, or the most perfect UX that a team can not decide on what it is will only make the software more bloated than it's reasonable, and fill it with bugs.
Of course, making mistakes is only human, but mistakes should never get past the build process (compilation, automated testing). Any mistake that does reflects an error in your design (not making your code amenable to verification) and/or your process (not capturing requirements in tests).
There are lots of good reasons to refactor - if indeed frivolous refactoring is more prevalent I would think this kind of opinion should be supported by a source/reference.
According to empirical studies, practicing TDD leads to a 90% (yes, that number is correct) post-ship bug reduction at an upfront cost of 15-35% more development time.
Which seems like a pretty good tradeoff, to me. (And I've experienced it firsthand.)
http://research.microsoft.com/en-us/groups/ese/nagappan_tdd....
Also discussed in this infoq article
http://www.infoq.com/news/2009/03/TDD-Improves-Quality
Here's someone's thesis paper on it, with data:
http://www.nomachetejuggling.com/files/tdd_thesis.pdf
There's also interesting discussions like this
http://programmers.stackexchange.com/questions/206355/the-re...
"it is my experience that the value proposition for TDD grows exponentially as the time and resources involved in a project grows linearly."
This has also been my own experience.
This person's comment also is interesting and has data
http://programmers.stackexchange.com/a/210756
Some of the above is empirical (read: scientific, no-bullshit) data.
My opinion on it has grown to the point that I think TDD should literally be inseparable from programming, and the two together should simply be called, "programming." Lacking any unit tests whatsoever (TDD or otherwise) should be called, "taking stupid, extremely hazardous risks to save a little time, like reading your phone while driving"
I've not found a programming task in at least 5 years that wasn't waaaay better-written when done via TDD. Some things, like IO, can be a challenge to unit-test, but that's why we have great ideas to solve that like Gary Bernhardt's awesome "Boundaries" talk https://www.youtube.com/watch?v=yTkzNHF6rMs
Yes. It's pretty easy to write provably correct software, just expensive.
> Developers are often guilty of just refactoring for no particularly good reason other than their personal sense of aesthetic, which can lead to endless (and destructive) refactoring
Not my experience, but even if so, if you require your software to be proven correct then it won't matter - any refactor that breaks it simply won't be accepted.
> More money also makes people design lazy, so that instead of finding clever ways to reduce effort and improve uniformity, you just have everyone make their own forms.
Um what? What does this have to do with anything?
As another example, when I was logged in to my mutual fund web site, I found a button that says Get Statement. Since I wanted to download one, I clicked it, and it said, "Your statement will arrive in the post soon." They sent a paper statement without confirming me what I wanted. When it arrived, I threw it away, of course.
In many cases, poorly built software increases costs for the company as well, so financial incentives are only part of the story. Incompetence is another part, maybe a bigger one.
It may sound silly to some but I'm really interested in what people think about this.
If you ship something that loses data and you have to start restoring backups and patching data, it probably would've been cheaper to do a little extra testing.
Like everything; it's a tradeoff. I think we're universally bad at playing the game!