Although pride of workmanship improves profit it's viewed as a counter to the current direction of the wind. This is a matter for which management will ultimately be blamed. However, as producers you should learn to understand the source of the flawed code beyond time constraints.
"Management creates quality", W Edwards Deming
Also, understand your role and the role of your company. Not every level of craftsmanship is appropriate for every level of project.
Though not helpful, I will give you examples of code issues (Java):
I wouldn't actually call most of these code issues.
1) People check not null against ResultSet.getInt() in JDBC (to check if a nullable Integer column is in fact null or not), when it can never return null (and checking for 0 is also wrong because it might be a valid value).
This is an actual code problem. Start a pattern of using a result set wrapper or a utility library so that people don't have to keep remembering to use wasNull().
2) People acquire a lock before try catch block (where catch blocks rethrow exceptions), and don't release it in a finally block.
Another problem although thankfully one that's fairly easy to mitigate (manual locks are generally although not always fairly rare and can trigger manual code reviews; if this is a major problem then a lock wrapper can be used that releases locks when its going out of scope, etc).
3) Many objects have a getJSON() function where we create JSON by hand (using string constant and +s). And this is not a debug string - these go into our server logs, which are parsed downstream by hadoop jobs.
This, I don't see as a problem and and of itself. The function is completely self-contained and its implementation can be ignored by all users of the class. Its possible that it does things that using a JSON library would be annoying about, like sometimes trimming/masking certain strings or making sure that the output text is always in a consistent order - also, while adding annotations to internal attributes/methods to indicate inclusion/exclusion is a good idea, if the output is intended for a specific consumer rather than general use and the formats are basically fixed, putting all of the logic into one method may be ultimately cleaner.
If those aren't the case, its also something that can be trivially refactored from inside the classes.
4) Inside a class we assume the member is immutable, whereas one of the getters returns a mutable copy of that object.
That's a problem alright, but probably easier to fix then to complain about, no?
5) We have some encryption and decryption in our workflow. The classes which have have the encryption/decryption algorithm have a lengthy init, but don't maintain any state. Yet we create a new object of that class for every request in our server.
Also not a code issue IMO - sounds like a well abstracted design. If long-lived utilities are more efficient, then the injected/instantiated class can be modified in one place to do whatever state management is needed and the users of the utility should never notice anything other than a speed improvement.
We know this because when we work on some of our code, we try to "update" to a higher quality standard, and have found such issues and fixed them.
And how long did that take? What risks were introduced in touching code that worked? Were those areas also identified to QA to test independently of the documented issue that was being worked on? Refactoring code that's regularly modified and frequently triggers bugs really pay off, but that doesn't mean that the refactoring is "free" either in time or risk. Sometimes even performance tuning a heavily relied upon piece of code, such as an encrypt/decrypt routine, wouldn't be worth it if the refactoring introduced even a single production issue, whereas throwing more hardware at the problem is fairly safe. Development shouldn't be making those decisions in a vacuum without understanding the business implications.
The OP has outlined the reasons for why the code is bad - such as buggy releases, lack of test coverage etc. That indicates that the code or process is bad, somewhere.
Buggy releases are a good sign that there's a problem (assuming that the bugs actually are significant in impact, of course). Lack of test coverage though is a symptom that may explain how bad releases happen, but is not in and of itself a cause of bad releases or bad code. I've seen plenty of truly poorly written and unmaintainable code that had 100% test coverage (although the tests were often testing the wrong things), and plenty of nice, clean, maintainable code that didn't have tests associated with it (at least partially because it'd be factored down to simple, understandable methods that "didn't need" comprehensive automated testing because, once written (to do one thing with no side effects at the same internal mental level) they were rarely if ever touched and the extra (small but significant) time to spend writing tests for mostly write-once code would have been a bad business decision.
Having said that, there's plenty of time that developers (myself included) should have better, smarter test coverage. Automated unit and integration tests are amazingly useful - but they're not the end-goal of software development, just another tool in the belt.
Trying to force your preferred coding style on to developers who operate differently will never end well. Unless you are uncommonly versatile, adapting yourself to a standard you hate will also not go well.
Also, when developing, realize that having consistent code that matches the rest of the project is far more useful than having a small chunk of code that - to you - is slightly more readable in and of itself but dissimilar to everything else. Most (although not all) coding standards, after all, are relatively trivial.
With Java, at least you have the official Sun recommendation to start with which almost every project follows somewhat. I prefer to operate as a diff of the standard - "Follow the guidelines, but lines up to XX characters are fine", for example.
2) Writing very clean code, and then keeping it clean, does NOT save you time in the long run. While it does reduce bugs and (in theory) makes it faster to add features in the future, the length of time it takes to write the code in the first place exceeds the time saved by fewer bugs, and the future features must also be clean, which *always* requires more refactoring than you would expect.
A very good point. If your code is well compartmentalized this gets even less efficient - if you have a big hairy ball of code that only gets tweaked once a year, but each "5 minute" fix ends up taking a full day of testing and hair-pulling, spending a month or two to fix it just won't ever pay off, especially when you add in the opportunity cost of missing a month's worth of new feature development.
You need to find a new doctor - an actual GP who you go to see for well-checks as well as when you're sick, rather than a doc-in-the-box clinic. Then 5-15 minutes should be much more like it.
Of course, by the same logic, a metal key is easily defeated with a small (but strong) highly adhesive sticker over the keyhole (or just some crap shoved into the lock if you're feeling really mean), whereas a remote entry device has no such limitation. Or a minor physical imperfection in the key itself, of course. Silly arguments work both ways, you know. This isn't a problem in the real world because most people are good most of the time.
My 2 year old Honda begs to differ. There's a passive chip in the key, and you have to go through the registration process to teach your car about a new key that you cut, but it has nothing to do with the remote fob.
With my iPhone I have to carefully plan my app usage, and I basically expect to run out of power pretty much daily (late afternoon).
Or you can simply plug in an external battery that fast-charges the internal one in a matter of minutes (during which time your phone is ever so slightly thicker). Or leave it attached, providing case-like protection, and have the option to remove the phone and have a smaller lighter device when you need it to.
The reality is that the vast majority of people never swap batteries in their phones. Most people never even replace them once. For those who need extra capacity for an iPhone there are many nice, reasonably priced solutions available for basically the cost of an extra battery, that weigh about as much as an extra battery so are no harder to carry around.
Optimize for the common case, handle the uncommon case gracefully. What is the problem here exactly?
No... but prove innocence or be willing to talk to the cops when your neighbor gets murdered seems reasonable.
No smoke without fire?
Turns out that when you see a lot of smoke, its often worth checking to see if there's a fire. There isn't always, but there often is. Its one reason we have fire extinguishers in kitchens and workshops.
Where it would get really interesting is with advanced compiler inspections. For example, let's say that you modified data within the loop, but only through atomic writes:
i = 0; for every bunny in list {
++i; }
Silly example, I know, but in this particular case it still doesn't matter if the loop is parellized. ( i = i + 1 , however, would be a disaster unless it was initially optimized into an increment operation).
I completely agree that it might give him some special insight into identifying areas of optimization need (although if he's rusty with the products, probably not so much). However, that's more of a business-analyst role traditionally and still doesn't necessarily translate into any expertiese in working on the system itself. There's no guarantee that an amazingly good SQL designer could even program in the close-to-embedded-level C code typically used in enterprise-class database engines.
You write: "I've done a good bit of SQL development / tuning in the past.... My problem is choosing which OSS DB to help with."
That's akin to saying, "I've done a good bit of SCCA track racing in the past. My problem is choosing which engine builder to intern with." Or even, "I'm an amazing, although out-of-practice chef. Should I work on enhancing Viking or Maytag gas ranges?"
Using a database (or any product) very effectively often has little or not translation into working on the guts of the product.
Not only that, but $24 in parts cost plus additional labor cost (the iPad mini looks significantly trickier to assemble than the Fire does), and it certainly doesn't appear out of line.
Defining "commercial use" gets to be tricky indeed. For example, most movie theaters make no money selling tickets (all of that goes back to the studios), they make their money on concessions. If they could "get ahold" of a digital copy (which most won't do because showing it would be illegal and easily punished) and then show it legally, for free, open to the general public (ie: non-commercial use) but then have unaffiliated food and beverage sales, they would. And there goes most of the studio's revenue stream.
Just beware - depending on the situation, this can actually increase your civil liability. The example I've seen happen is where someone was attacked outside a business; when the tapes were requisitioned the cameras were found to be false. The case was argued, successfully I believe, that the business had engendered a false sense of security by implying that they had taken precautions that they had not, in fact, taken. I don't remember the specifics, but its worth a quick word with your attorney before you do this in a "public" place like a business to make sure that you're correctly covered.
Yup - I had a 15 year old ranger (~90hp new, 5-speed, 4 cyl). It was just fine. Sure, you needed to plan ahead a little more and couldn't just mosey onto the highway and then punch it, but I drove it on 35 and MoPac every day with no problems.
Slashdot Mirror
Don't rock the boat.
Although pride of workmanship improves profit it's viewed as a counter to the current direction of the wind. This is a matter for which management will ultimately be blamed. However, as producers you should learn to understand the source of the flawed code beyond time constraints.
"Management creates quality", W Edwards Deming
Also, understand your role and the role of your company. Not every level of craftsmanship is appropriate for every level of project.
Though not helpful, I will give you examples of code issues (Java):
I wouldn't actually call most of these code issues.
1) People check not null against ResultSet.getInt() in JDBC (to check if a nullable Integer column is in fact null or not), when it can never return null (and checking for 0 is also wrong because it might be a valid value).
This is an actual code problem. Start a pattern of using a result set wrapper or a utility library so that people don't have to keep remembering to use wasNull().
2) People acquire a lock before try catch block (where catch blocks rethrow exceptions), and don't release it in a finally block.
Another problem although thankfully one that's fairly easy to mitigate (manual locks are generally although not always fairly rare and can trigger manual code reviews; if this is a major problem then a lock wrapper can be used that releases locks when its going out of scope, etc).
3) Many objects have a getJSON() function where we create JSON by hand (using string constant and +s). And this is not a debug string - these go into our server logs, which are parsed downstream by hadoop jobs.
This, I don't see as a problem and and of itself. The function is completely self-contained and its implementation can be ignored by all users of the class. Its possible that it does things that using a JSON library would be annoying about, like sometimes trimming/masking certain strings or making sure that the output text is always in a consistent order - also, while adding annotations to internal attributes/methods to indicate inclusion/exclusion is a good idea, if the output is intended for a specific consumer rather than general use and the formats are basically fixed, putting all of the logic into one method may be ultimately cleaner.
If those aren't the case, its also something that can be trivially refactored from inside the classes.
4) Inside a class we assume the member is immutable, whereas one of the getters returns a mutable copy of that object.
That's a problem alright, but probably easier to fix then to complain about, no?
5) We have some encryption and decryption in our workflow. The classes which have have the encryption/decryption algorithm have a lengthy init, but don't maintain any state. Yet we create a new object of that class for every request in our server.
Also not a code issue IMO - sounds like a well abstracted design. If long-lived utilities are more efficient, then the injected/instantiated class can be modified in one place to do whatever state management is needed and the users of the utility should never notice anything other than a speed improvement.
We know this because when we work on some of our code, we try to "update" to a higher quality standard, and have found such issues and fixed them.
And how long did that take? What risks were introduced in touching code that worked? Were those areas also identified to QA to test independently of the documented issue that was being worked on? Refactoring code that's regularly modified and frequently triggers bugs really pay off, but that doesn't mean that the refactoring is "free" either in time or risk. Sometimes even performance tuning a heavily relied upon piece of code, such as an encrypt/decrypt routine, wouldn't be worth it if the refactoring introduced even a single production issue, whereas throwing more hardware at the problem is fairly safe. Development shouldn't be making those decisions in a vacuum without understanding the business implications.
Somewhat agree...
The OP has outlined the reasons for why the code is bad - such as buggy releases, lack of test coverage etc. That indicates that the code or process is bad, somewhere.
Buggy releases are a good sign that there's a problem (assuming that the bugs actually are significant in impact, of course). Lack of test coverage though is a symptom that may explain how bad releases happen, but is not in and of itself a cause of bad releases or bad code. I've seen plenty of truly poorly written and unmaintainable code that had 100% test coverage (although the tests were often testing the wrong things), and plenty of nice, clean, maintainable code that didn't have tests associated with it (at least partially because it'd be factored down to simple, understandable methods that "didn't need" comprehensive automated testing because, once written (to do one thing with no side effects at the same internal mental level) they were rarely if ever touched and the extra (small but significant) time to spend writing tests for mostly write-once code would have been a bad business decision.
Having said that, there's plenty of time that developers (myself included) should have better, smarter test coverage. Automated unit and integration tests are amazingly useful - but they're not the end-goal of software development, just another tool in the belt.
Trying to force your preferred coding style on to developers who operate differently will never end well. Unless you are uncommonly versatile, adapting yourself to a standard you hate will also not go well.
Also, when developing, realize that having consistent code that matches the rest of the project is far more useful than having a small chunk of code that - to you - is slightly more readable in and of itself but dissimilar to everything else. Most (although not all) coding standards, after all, are relatively trivial.
With Java, at least you have the official Sun recommendation to start with which almost every project follows somewhat. I prefer to operate as a diff of the standard - "Follow the guidelines, but lines up to XX characters are fine", for example.
2) Writing very clean code, and then keeping it clean, does NOT save you time in the long run. While it does reduce bugs and (in theory) makes it faster to add features in the future, the length of time it takes to write the code in the first place exceeds the time saved by fewer bugs, and the future features must also be clean, which *always* requires more refactoring than you would expect.
A very good point. If your code is well compartmentalized this gets even less efficient - if you have a big hairy ball of code that only gets tweaked once a year, but each "5 minute" fix ends up taking a full day of testing and hair-pulling, spending a month or two to fix it just won't ever pay off, especially when you add in the opportunity cost of missing a month's worth of new feature development.
Personally, I'm relieved and surprised to find that 'value' beef burgers actually contain meat from named mammals. :-)
Trigger, Dobbin... Rex, perhaps?
You need to find a new doctor - an actual GP who you go to see for well-checks as well as when you're sick, rather than a doc-in-the-box clinic. Then 5-15 minutes should be much more like it.
Worse, a software patent can cover the idea of creating Salicylaldehyde, without anyone ever needing to have done so.
Of course, by the same logic, a metal key is easily defeated with a small (but strong) highly adhesive sticker over the keyhole (or just some crap shoved into the lock if you're feeling really mean), whereas a remote entry device has no such limitation. Or a minor physical imperfection in the key itself, of course. Silly arguments work both ways, you know. This isn't a problem in the real world because most people are good most of the time.
My 2 year old Honda begs to differ. There's a passive chip in the key, and you have to go through the registration process to teach your car about a new key that you cut, but it has nothing to do with the remote fob.
With my iPhone I have to carefully plan my app usage, and I basically expect to run out of power pretty much daily (late afternoon).
Or you can simply plug in an external battery that fast-charges the internal one in a matter of minutes (during which time your phone is ever so slightly thicker). Or leave it attached, providing case-like protection, and have the option to remove the phone and have a smaller lighter device when you need it to.
The reality is that the vast majority of people never swap batteries in their phones. Most people never even replace them once. For those who need extra capacity for an iPhone there are many nice, reasonably priced solutions available for basically the cost of an extra battery, that weigh about as much as an extra battery so are no harder to carry around.
Optimize for the common case, handle the uncommon case gracefully. What is the problem here exactly?
Especially since the cost of his actions far outweighs that of a reasonable bribe under those circumstances.
Prove innocence or go to jail?
No... but prove innocence or be willing to talk to the cops when your neighbor gets murdered seems reasonable.
No smoke without fire?
Turns out that when you see a lot of smoke, its often worth checking to see if there's a fire. There isn't always, but there often is. Its one reason we have fire extinguishers in kitchens and workshops.
Every house, particularly those with children, should have a globe. Mine are next to each other on the book shelf, about ten feet away at the moment.
Its great that they're reading the globe, but should you really keep your children on the book shelf like that?
Where it would get really interesting is with advanced compiler inspections. For example, let's say that you modified data within the loop, but only through atomic writes:
i = 0;
for every bunny in list {
++i;
}
Silly example, I know, but in this particular case it still doesn't matter if the loop is parellized. ( i = i + 1 , however, would be a disaster unless it was initially optimized into an increment operation).
Fun times!
I completely agree that it might give him some special insight into identifying areas of optimization need (although if he's rusty with the products, probably not so much). However, that's more of a business-analyst role traditionally and still doesn't necessarily translate into any expertiese in working on the system itself. There's no guarantee that an amazingly good SQL designer could even program in the close-to-embedded-level C code typically used in enterprise-class database engines.
You write: "I've done a good bit of SQL development / tuning in the past. ... My problem is choosing which OSS DB to help with."
That's akin to saying, "I've done a good bit of SCCA track racing in the past. My problem is choosing which engine builder to intern with." Or even, "I'm an amazing, although out-of-practice chef. Should I work on enhancing Viking or Maytag gas ranges?"
Using a database (or any product) very effectively often has little or not translation into working on the guts of the product.
Ever seen a modern locomotive? Scaling power in an electric car is far, far easier than scaling it in a fossil-fuel equiv. vehicle.
Not only that, but $24 in parts cost plus additional labor cost (the iPad mini looks significantly trickier to assemble than the Fire does), and it certainly doesn't appear out of line.
You seen to know different teenagers than I do.
I'd hope so. I mean, slashdot has an international reach and all that. What are the odds?
Defining "commercial use" gets to be tricky indeed. For example, most movie theaters make no money selling tickets (all of that goes back to the studios), they make their money on concessions. If they could "get ahold" of a digital copy (which most won't do because showing it would be illegal and easily punished) and then show it legally, for free, open to the general public (ie: non-commercial use) but then have unaffiliated food and beverage sales, they would. And there goes most of the studio's revenue stream.
Don't remember and poor google-fu today, but lots of reputable blogs (written by lawyers, such as http://www.securityinfowatch.com/article/10546713/the-legal-side-liability-for-installed-surveillance-cameras?page=2 ) and security pages refer to the issue.
Let's just say that there's a reason the Firefox logo on the story is shown facing away from the camera, and leave it at that.
Just beware - depending on the situation, this can actually increase your civil liability. The example I've seen happen is where someone was attacked outside a business; when the tapes were requisitioned the cameras were found to be false. The case was argued, successfully I believe, that the business had engendered a false sense of security by implying that they had taken precautions that they had not, in fact, taken. I don't remember the specifics, but its worth a quick word with your attorney before you do this in a "public" place like a business to make sure that you're correctly covered.
Yup - I had a 15 year old ranger (~90hp new, 5-speed, 4 cyl). It was just fine. Sure, you needed to plan ahead a little more and couldn't just mosey onto the highway and then punch it, but I drove it on 35 and MoPac every day with no problems.
Interesting, but I would have preferred to have our /. robotic overlords read TFA to me in the voice of James Doohan.
He's dead, Jim.
Now, if you mean't zombie James Doohan, that'd be a different kettle of fish entirely.