101–110 of 132 posts
Earlier quoted context omitted.
From memory: the Excel bug that caused Moody's to give high ratings of mortgage securities (one of the probable causes of the whole mess) was known, but management decided not to fix it. So, greed can override checks and balances.
The bug wasn't in Excel. It was Moody's own fault, not Microsoft's.
This actually made things worse. Aggressive releases were often the result of a decision further up the chain that something was "critical" and needed to go out right then and there. We'd got into the pattern of expecting to be able to do this at the drop of a hat.
So now, everyone was rushing to get the "urgent fix" into the daily release. This is an effective way to ship buggy software. Extra emergency releases were frowned upon, and so it introduced a level of panic that "Oh shit, this better not screw everything up". Ironically, with anyone releasing whenever they wanted, there was less panic because you could always make a quick fix and put it out without too many people noticing or caring.
We felt as a team that we'd prefer a more relaxed schedule that also allowed testing and accountability.
Frequent releases were a result of bad management, and unrealistic stakeholder expectations, we as developers didn't necessarily care that our code wasn't being put out immediately. Obviously, it needs to go out at some point, and we've been equally demoralised by mammoth projects that have gone on for months without a release, but that's a different end of the spectrum. The important thing is regular releases, not frequent ones.
We've now decided to move to releases every 2 weeks with a 1 week QA period. We made this decision as a team of developers, it wasn't handed down from above, it just became a necessary check for the scale of our company.
I personally feel a lot more productive as a result, less panicked by the quick fix you need to drop everything to fit into the daily release, and less worried that a release will take out the site.
But sure, it comes at a cost. There's now a lot more going out with each release and more variables that could combine to cause issues, but these issues highlight deficiencies in our QA process that can be fixed. Also, getting our team to work according to this 2 week schedule has meant some significant costs to adopt better development processes, namely SCRUM, but I feel our team has benefited enormously from it. It all depends how well your team can adapt really.
So yes, there are costs associated, but it doesn't necessarily lead to demotivated developers. You need to be sure that the checks are introduced properly with their own test suite. This itself has a cost but can be extremely worthwhile. A half arsed and arbitrary change to your release schedule with no process changes can destroy you, but with a little training, the right team and the right managers, you can make things better for everyone.
I would call it part of institutionalisation. You have a need to be effective via policies, checks, procedures & such. This replaces the shoot from the hip of small groups.
I think you can apply this to schools that need to teach approved courses with approved grading. Then it gets worse when they need examinations that are to be applied across an entire country.
I'm sure there are principals that can be extracted & applied to lots of places. The costs can be very serious.
Earlier quoted context omitted.
I meant these particular guys.
My point still is valid. Even these particular guys certainly would have written buggy code. A QA process could correct it.
Also, bugs do appear in production if you can release code the same day you wrote it, but you can fix it as soon as you find out about it. In big companies that work with milestones (sprints in agile speak), only really critical bugs can be fixed between releases. Not to mention that most bugs are fixed after code-freeze, when all the deliverables of that milestone are ready, long after you find out about it.
So I guess it's best to have QA, but also the freedom to deploy code on production whenever you want.
Earlier quoted context omitted.
You aren't a typical non-early-adopter user. I've had people make loud, public complaints about such trivial matters as a new logo being too tall, or a text box being too wide, or an optional WYSIWYG editor feature ruining the "text-only flavor of the community". These on websites far smaller than GMail. Look at some of the major Web2.0 kerfuffles in recent years. Off the top of my head, I can think of: - The HD/DVD…
None of these were the kind of bug that comes from releasing code with insufficient testing. The only one that even involved code was the Reddit password problem, and that was more a design mistake than a bug.
Earlier quoted context omitted.
You can't do anything well without liking to do it. The difference between hackers and salesmen is that hacking is what hackers like most. Salesmen who have sufficient money seem empirically to prefer playing golf, whereas hackers with money tend to keep hacking.
That doesn't change the fact that while they are working, they prefer to be getting lots of sales. They like to get paid for it, they can even be greedy. They like to get recognition for it, that can go to far too. But they also enjoy making the sale.
to me, hacking > sales (no, charity/non-profit/giving away money doesn't count -> there's moral incentive there)
I'm surprised you didn't tie this in to due diligence checks done by VCs, and its impact on startups, etc. The parallels are strong, and you've commented on that impact before (at FOWA in 2007, I think).
Regards, Terry Jones
Programmers are unlike many types of workers in that the best ones actually prefer to work hard. This doesn't seem to be the case in most types of work. When I worked in fast food, we didn't prefer the busy times. And when I used to mow lawns, I definitely didn't prefer it when the grass was long after a week of rain. Programmers, though, like it better when they write more code. Or more precisely, when they release…
Having never had a "normal" job per se (okay, I bagged groceries for a year when I was younger), I still find it hard to believe that it can take two weeks just to get something deployed. Maybe one day I'll finally truly believe all the stories I've heard -- two-week deployments, meetings about future meetings, etc. For now, some part of me still believes it's simply implausible and everyone is engaging in hyperbole.…
Mental Poisons are ideas that harm people, life and the universe. They are remarkably common.
Paul expresses this one very well. There's a lot more out there too.
Fossilised heirarchies and thought-free-rule-driven organisations are great for the student of poisons.