You've answered your own question: an elegant one-liner coupled with a comment from a few revisions ago makes for a good headache.
Clever code and maintainable code are not antagonistic. Clever code that's well commented is as maintainable as the more pedestrian type. There are two problems.
The first is that the second version is often an awful hack by a programmer, not the one who wrote the original code, who doesn't fully understand what the code is doing. There is no law, not even a best practice, that says all code, even well-commented code, must be comprehensible to someone with a two-digit IQ.
The second problem is getting said programmer to comment what he did. I suspect in many cases he doesn't know, except that the immediate symptoms have gone away. I call this a goat's blood and chicken feathers patch. Unintended consequences will be someone else's problem.
Maintainability is only one of many important quality attributes. I've written more 'clever' bits of code than I care to count, usually because the alternative would result in failing some other measure--response time, size, reliability, you name it. In every one of those cases the comments provided a technical manual for the subject code.
There's one case I won't forget where 14 lines of assembler was supported with 40 lines of comment, not including the comments on each line. I was invoking little-used and poorly documented features of the cpu chip and using them in an interesting way, and an explanation was appropriate. This code still runs fine on a modern PC. (If anyone is interested in a really fast x86 triple precision integer division that handles the signs of the quotient and remainder according to the Forth standard, I've got one.)
Clever code isn't the problem; poor documentation by poor programmers is the problem.
The resolution to the documentation problem is simple. I use it on my projects and when I managed programmers, I made them do it. Unfortunately, it needs discipline--the difference between programming and engineering--which is in short supply in the FOSS community.
The resolution is that you write the relevant section of the user manual first, have the client review it for clarity and sanity, and then make the software do exactly what the manual says.
Given the fuzziness of his source data, a claimed sigma of 1.5% for his magic constant is strong evidence of a fatal flaw in his model. It needs a much closer look.
I couldn't find a copy of the actual paper. If anyone knows where to find it, please let us know.
What these people fail to understand is that buying an extended warranty causes failures. I never buy the extended warranty and my gadgets experience negligible failure rates. The last thing I've had fail was a 12 year-old TV set.
The alternate explanation is that people who buy extended warranties are people whose experience indicate that it's a good investment--the klutzes.
Relational databases represent several decades of research into designing and building relational databases.
There are other kinds of databases, and problems to be solved that aren't easily modeled as tables. There's a reason for the agony over "object-relational impedance mismatch." The common answer--to build object models that are restricted to looking like relations (findByXXX is the smoking gun) gives up much of the power of objects.
Relational databases solve problems that look like relations. That's a subset of all the problems to be solved--and it's shrinking.
You're confused because you are thinking in SQL terms. When you open your inbox, in Facebook, it doesn't search at all; it follows the link to your inbox.
Think of it this way: In a relational database, you find Alice's marbles by asking every marble in the universe whether it belongs to Alice. In an OO, hierarchical, or key/value database, you ask Alice for her list of marbles.
Codd's model was designed without regard to speed; the design imperatives were integrity and minimal size, in that order. We no longer have expensive and unreliable storage to worry about and most of our applications are tolerant of temporary inconsistencies.
This is not new. Seven years ago I built a system whose only viable database solution involved three database instances with references going between tables in different instances (dropping referential integrity over the side). I was forced by "corporate architecture" to use a relational database product. The solution with something like BerkelyDB would have been a whole lot simpler and a whole lot faster in construction, deployment and production.
On another project, I was dealing with an anal-retentive DB group who were very slow delivering the database. As a stop-gap, we built a layer below the objects that used the file system. Directories for classes, one file per object. The fun thing about this is that the system ran between 3 and 4 times as fast with the file system than it did with the eventual Oracle DB. You can blame object-relational impedance for some of that but not all.
When you consider how much well-deserved ridicule has been levelled at PowerPoint and it's users by people with outstanding communications credentials, how is it than anyone can fire up a "deck" without being laughed out of the room?
From your post, I'm going to assume that you are talking about a routine status report and not a one-time stand-up presentation, so we don't have to worry about whether you have a fresh haircut or how nicely you're dressed.
What your management wants is assurance that all is in order and, if it's not, where's the problem? This can usually be done with a few numbers and/or graphs. Metrics.
The first thing you need to know is what is important to your users (and the owners of the devices you refer to).
The second thing is to figure out what you can count that says something about how those things are being supported. Find unambiguous metrics, so that you could send five people out to do the counting and they'd all come back with the same value.
The third thing is to design effective presentations for the data. As a manager, what I'm going to want to know is
What's the current value?
What's an acceptable range?
What's the trend?
One metric can easily be presented with a couple of numbers and a sparkline for the trend (read Beautiful Evidence, Edward Tufte). You can use Excel's graph feature to make the sparklines. You can mark the acceptable range on the sparkline for maximum clarity.
You can probably report everything you should with at most a half-dozen metrics across the top of a sheet of paper, followed by whatever narrative is needed to highlight points of interest. Take a look at http://tanda.on.ca/notebook/securitydashboard.html for an example.
So, in this corner we have Embedded Open Type which has been supported by the last four versions of IE, but little used because no one wants to use features tied to one browser.
In the other corner, we have the challenger, WOFF, the new kid in town.
Will one of them win or will they battle to a draw, leaving web designers with a choice between using web-safe fonts and the work of supporting two standards. In the latter case, we'll be stuck with boring typography for years.
EOT is on its way through W3C standardization. WOFF is still a prototype that smells like yet another "anything but Microsoft" ploy.
Let's hope that Microsoft decides to humour them.
Slashdot Mirror
You've answered your own question: an elegant one-liner coupled with a comment from a few revisions ago makes for a good headache.
Clever code and maintainable code are not antagonistic. Clever code that's well commented is as maintainable as the more pedestrian type. There are two problems.
The first is that the second version is often an awful hack by a programmer, not the one who wrote the original code, who doesn't fully understand what the code is doing. There is no law, not even a best practice, that says all code, even well-commented code, must be comprehensible to someone with a two-digit IQ.
The second problem is getting said programmer to comment what he did. I suspect in many cases he doesn't know, except that the immediate symptoms have gone away. I call this a goat's blood and chicken feathers patch. Unintended consequences will be someone else's problem.
Maintainability is only one of many important quality attributes. I've written more 'clever' bits of code than I care to count, usually because the alternative would result in failing some other measure--response time, size, reliability, you name it. In every one of those cases the comments provided a technical manual for the subject code.
There's one case I won't forget where 14 lines of assembler was supported with 40 lines of comment, not including the comments on each line. I was invoking little-used and poorly documented features of the cpu chip and using them in an interesting way, and an explanation was appropriate. This code still runs fine on a modern PC. (If anyone is interested in a really fast x86 triple precision integer division that handles the signs of the quotient and remainder according to the Forth standard, I've got one.)
Clever code isn't the problem; poor documentation by poor programmers is the problem.
why should you expect one to be able to explain how to use the software to the other?
Actually, I'm expecting the client to make it clear to the programmer how he expects to use the software.
That's an interesting argument against Agile. Are you sticking to it?
The resolution to the documentation problem is simple. I use it on my projects and when I managed programmers, I made them do it. Unfortunately, it needs discipline--the difference between programming and engineering--which is in short supply in the FOSS community.
The resolution is that you write the relevant section of the user manual first, have the client review it for clarity and sanity, and then make the software do exactly what the manual says.
Pause to recover composure
What could I be thinking?!
This is quite possibly the silliest substitute for a 20mm cannon ever proposed.
OK--found it. I was getting a "not responding" on the pdf link before.
Now to make some sense of it.
Given the fuzziness of his source data, a claimed sigma of 1.5% for his magic constant is strong evidence of a fatal flaw in his model. It needs a much closer look.
I couldn't find a copy of the actual paper. If anyone knows where to find it, please let us know.
What these people fail to understand is that buying an extended warranty causes failures. I never buy the extended warranty and my gadgets experience negligible failure rates. The last thing I've had fail was a 12 year-old TV set.
The alternate explanation is that people who buy extended warranties are people whose experience indicate that it's a good investment--the klutzes.
That's a girl's round. How about a nice 50.
Perhaps you want to think this through again?
How can ssh connect two isolated networks? Linux software is pretty powerful, but I don't think it extends to stringing wire and installing routers.
Oops, he said "never". That makes it propaganda, not science.
Relational databases represent several decades of research into designing and building relational databases.
There are other kinds of databases, and problems to be solved that aren't easily modeled as tables. There's a reason for the agony over "object-relational impedance mismatch." The common answer--to build object models that are restricted to looking like relations (findByXXX is the smoking gun) gives up much of the power of objects.
Relational databases solve problems that look like relations. That's a subset of all the problems to be solved--and it's shrinking.
You're confused because you are thinking in SQL terms. When you open your inbox, in Facebook, it doesn't search at all; it follows the link to your inbox.
Think of it this way: In a relational database, you find Alice's marbles by asking every marble in the universe whether it belongs to Alice. In an OO, hierarchical, or key/value database, you ask Alice for her list of marbles.
Codd's model was designed without regard to speed; the design imperatives were integrity and minimal size, in that order. We no longer have expensive and unreliable storage to worry about and most of our applications are tolerant of temporary inconsistencies.
This is not new. Seven years ago I built a system whose only viable database solution involved three database instances with references going between tables in different instances (dropping referential integrity over the side). I was forced by "corporate architecture" to use a relational database product. The solution with something like BerkelyDB would have been a whole lot simpler and a whole lot faster in construction, deployment and production.
On another project, I was dealing with an anal-retentive DB group who were very slow delivering the database. As a stop-gap, we built a layer below the objects that used the file system. Directories for classes, one file per object. The fun thing about this is that the system ran between 3 and 4 times as fast with the file system than it did with the eventual Oracle DB. You can blame object-relational impedance for some of that but not all.
When you consider how much well-deserved ridicule has been levelled at PowerPoint and it's users by people with outstanding communications credentials, how is it than anyone can fire up a "deck" without being laughed out of the room?
The car analogy is appropriate, given that this thing is the size of a minivan.
There's a standard approach to doing this.
From your post, I'm going to assume that you are talking about a routine status report and not a one-time stand-up presentation, so we don't have to worry about whether you have a fresh haircut or how nicely you're dressed.
What your management wants is assurance that all is in order and, if it's not, where's the problem? This can usually be done with a few numbers and/or graphs. Metrics.
The first thing you need to know is what is important to your users (and the owners of the devices you refer to).
The second thing is to figure out what you can count that says something about how those things are being supported. Find unambiguous metrics, so that you could send five people out to do the counting and they'd all come back with the same value.
The third thing is to design effective presentations for the data. As a manager, what I'm going to want to know is
One metric can easily be presented with a couple of numbers and a sparkline for the trend (read Beautiful Evidence, Edward Tufte). You can use Excel's graph feature to make the sparklines. You can mark the acceptable range on the sparkline for maximum clarity.
You can probably report everything you should with at most a half-dozen metrics across the top of a sheet of paper, followed by whatever narrative is needed to highlight points of interest. Take a look at http://tanda.on.ca/notebook/securitydashboard.html for an example.
Yah. There was a time I was corresponding with a guy in Minsk. The bang path was 22 hops, including a diskette carried between East and West Berlin.
Sounds like uucp over zmodem.
First, teach them to understand Liverpuddlian.
So, in this corner we have Embedded Open Type which has been supported by the last four versions of IE, but little used because no one wants to use features tied to one browser.
In the other corner, we have the challenger, WOFF, the new kid in town.
Will one of them win or will they battle to a draw, leaving web designers with a choice between using web-safe fonts and the work of supporting two standards. In the latter case, we'll be stuck with boring typography for years.
EOT is on its way through W3C standardization. WOFF is still a prototype that smells like yet another "anything but Microsoft" ploy. Let's hope that Microsoft decides to humour them.
You probably want to give that a little more thought.
The short form is "The universe has one measure of success: the number of your descendants."
It's not logic, it's observation.
It's also the black swan to anyone who claims that evolution has stopped in humans.
As to their extrapolation, if you RTFA you'll see that it's carefully hedged.
As to credibility, who do you think are more likely to have lots of kids? Pitbull's women, or Madonna and friends?
What? You don't like your women curvy? The men of Framingham do.
Not at all.
Mesolithic and neolithic refer to cultures that existed at the same time. The time periods overlap.
Neolithic culture spread across Europe (more or less SE to NW) pushing out the indigenous mesolithic culture. At the boundary were neolithic raiders.
Do the research and we'll talk again if you have the guts to identify yourself.