61–70 of 237 posts
And that is how creativity dies. Not all at once with a swift, decisive blow. More like the bites of 10,000 mosquitoes coming 1 at a time, about every 5 minutes so you don't notice that they've stolen a significant amount of your blood until it's too late.
I just went through the same thing. Except I was smart (or so I thought) and had what I needed changed in a config file. PHB decided that it still counted as a "code" change because someone needed to log onto the box and change the config. Literally it was removing 3 characters from it. The only reason I even had it in the config was to avoid it being a code change to begin with. I argued back that in the time I woul…
the difference between config and code is largely illusionary, so PHB is right: both can break things and need to be tested.
I did forget to mention it did go though a round of testing, which took less then 5 minutes to be verified as correct. It literally was 6 days of process wrapped around 10 minutes work.
Honestly, for code that controls millions of dollars worth of business and could seriously screw over a lot of people if a subtle flaw was introduced, I don't see a problem with doing it this way. Might be overkill for one line of code, but where do you set the threshold? If you say any change longer than four lines is subject to this process, then people will work on trickling in new stuff in increments of four line…
In this case process overrode rationale; and was cheered as a result on its own.
And that is how creativity dies. Not all at once with a swift, decisive blow. More like the bites of 10,000 mosquitoes coming 1 at a time, about every 5 minutes so you don't notice that they've stolen a significant amount of your blood until it's too late.
No, this is how creativity is shut out after one too many incidents where she wandered in, decided to be helpful and, due to imperfect understanding how things work, caused massive loss of productivity, money and reputations.
That "legacy code must be brought up to current standards whenever it's touched" policy doesn't seem very wise. I'm all for practical refactoring, but it's a major decision to be treated with care when it comes to legacy code. You don't always want to invite it. I certainly wouldn't want to enforce it. I mean, it's one thing when your oldest legacy code is two years old, and it's all one program. It's something else…
I get the feeling that too many people in the chain did not treat this as an emergency. It seems very business as usual. When a company is talking layoffs, it is an emergency.
Earlier quoted context omitted.
What's a Cinderella problem? I'm assuming it's a reference to the midnight deadline.
The code behaves differently after some event happens. Midnight. Y2K. Daylight Savings Time change. Leap Day. Congress changes when Daylight Savings Time happens and one component in the system didn't know about it. Year 2038 problem.
Earlier quoted context omitted.
Reliability and quality are obviously important, but you have to question whether all these steps are actually helping you to achieve that. All of these items in the story add overhead and reduce agility, but potentially do very little to improve quality: - Mandatory paper trail via fields on the issue tracker - The need for documented internal sign offs - Standards and policies with no clear reason for the existence…
Exactly. The point bengl3rt was making, I assume, is that cavalier avoidance of process is a bad thing because it allows mistakes to happen that would be caught. That much is true. But the assumption that's wrong is that all processes avoid mistakes. Clearly they don't. And some of the examples here are just plain cargo cult misapplications of good ideas. The point behind code review is to catch design flaws in new c…
Skilled people without a process will always find a way to get things done. Skill begets process. But process doesn’t beget skill. Following a recipe won’t make you a great chef – it just means you can make a competent bolognese. Great chefs don’t need cookery books. They know their medium and their ingredients so well that they can find excellent combinations as they go. The recipe becomes a natural by-product of their work.
From http://the-pastry-box-project.net/cennydd-bowles/2012-march-...