Use the source. Again, brings the programmer out of their current objective, and this can often be tedious and error prone. That said, there is always a case where this is necessary/useful/insightful.
If reading source code takes you out of your current objective, you have a write-only view of programming, and that's a problem. Take a look at http://www.spinellis.gr/codereading/
For #4 you wrote about an error hander not checking for EFBIG or ENOSPC after writing to the error log. While it's certainly maximally robust to check that, in modern enterprise-scale systems it's going to be very rare. Now certainly I can imagine some context (say, Martian rovers...) where this kind of check would be much more necessary, I stand by my assertion that it's possible but rare.
The kind of thing I had in mind for novices writing speculative code is more related to what I call programmer-induced feature creep. In the worst cases this code for things that "might be needed in some future" is so buggy as to break the necessary features. Otherwise known as "gold plating"
3. I just knew that someone would bring up the complications of threads. Of course you are right -- but if a novice is solely responsible for tricky multi-threaded code, there's bigger problems!
4. Checking for possible but rare error conditions is robustness, and not what I had in mind. I wish I had a good example. Suffice to say that novices can come up with the most imaginative and oddball ideas about what users might want to do with the program someday.
It's not that hard to quantify the differences between a novice's code and an expert's. Here are some.
Novice code is longer. There will be three statements when one will suffice.
Novice code has duplication. You'll see the same thing done two ever-so-slightly different ways in two different place. An expert will abstract out the common code and vary on the thing that changes.
A novice will write redundant conditions and handlers where an expert will be concise. To give a Java example, in a catch clause, checking that the exception is not null (!)
Novices will code for all sort of imaginative things that *might* occur in some speculative future. Expert code will contain nothing that is not pertinent to the task at hand.
In the last 1960s, Al Bean had been assigned to the Apollo Applications project. He didn't expect to get into space for years, if ever. As it happened, his friend Pete Conrad needed someone to be LMP for Apollo 12, and knew Al was good and was working on long-term stuff that could wait. Al became the LMP for the flight, his first in space, and the 4th man to walk on the moon.
Everyone in the Astronaut training program is looking for their chance to jump the line and get wings, and you never know how might turn out to be the one to flip the critical switch for SCE to AUX and save the mission.
Bean later flew in space again as a Commander on the Apollo Applications mission that became Skylab.
That comment makes it abundantly clear that you know that it's never right up front. Why pad then? That's either a) cheating the customer, when your estimate turns out high or b) a gigantic risk of your company's profits if you guess low. Do you think the customer doesn't know you are padding? Of course they do -- negotiations up front on scope/price/schedule then end up being a struggle to push the padding one way or another. XP and similar agile methods want you and the customer to honest with each other and admit you don't know how big the thing will be, but that you will start delivering business value from very early, and allowing the customer to steer the project as it goes.
Consider two scheduled airline flights. On the first, the pilot points the nose in the direction he believes is towards the destination at take off and then after X hours begins a descent and landing expecting to be in the right place, and if not, hoping he put in enough extra fuel to be able to make it the rest of the distance to the airport. On the second, the pilot monitors the course, navigates along the way, and steers the plane with the necessary course corrections. He took off with sufficient fuel to make a normal flight, but all along the way he is sure he stays within range of safe landing sites in case of emergency.
it's still more cost-effective to get it right the first time wherever possible.
Even if that were true, it's never possible; not in the real world. Even in the pretend world, the effort needed to get the theoretical correct up front and for all time requirements is prohibitive. In the same theoretical play world where getting it right the first time is possible, you'd still find that the company would be bankrupt and the business problem to be solved would be moot before you were done.
Slightly off-topic, but I can cite prior art for use of ISBN numbers to trigger links to booksellers back to the mid/late 90s, when Amazon first created their affiliate program. One of the first Wikis would look for ISBN in the text of pages and automatically turn them into links to Amazon.
What you really want is the Memento Pattern. Intent: Without violating encapsulation, capture and externalize an object's internal state so that the object can be restored to this state later.
I agree generally with the other posters who warn against binary serialization and memory dumps. Define a format for writing out the memento object(s) that captures the necessary state but is easily parseable and extendable. A couple of formats that you've probably seen are the windows-style INI files and some kind of XML. There are lots of others.
Recently I received a copy of a memo forwarded by a CIO strongly in favor of moving towards buying applications over custom building them. While I can't reprint the memo here, I can speak to some of the points it made and respond to them from an alternate perspective. The memo summarizes one case study within the company of what is portrayed as a successful acquisition and implementation. The application is based on a vendor product and customized in-house to a limited extent. The case study asserts the benefits of the buy decision over three areas -- the technology, the cost, and quality.
In the memo, the author says that a system used by the business is based on a commercial application and claims 90% of it is standard and 10% is customized. There's no detail to justify that number, but suppose the software does 90% of what the customer needs. Left unmentioned in the memo is how much of the application is useful to the customer. In other words, what additional features and complexity is the business paying for with the application suite but not using? It's unlikely that 100% of the features of a commercial application are used by any one customer -- but can the business say it is using even 50% of them? Is that cost effective?
While the vendor's support may help keep the business current with technology, how much are the vendor updates just a way to keep the upgrade treadmill running? How often does the vendor introduce an update where none of the new or changed functionality is useful to the business? What is the cost of being on the vendor's development schedule, and how disruptive are upgrades? Worst of all, what happens when the vendor eliminates a feature that is key to the business?
The memo asserts that there is a significant cost savings to purchasing vendor-supported applications, because the costs of development are spread across all the customers. That's a bold assertion, but looking closer, to what extent is that cost savings eroded by the additional cost of features which are developed but not used in the business? Is the total cost of the software, including those elements useful to the business and those that are not, really less than a solution tailored to the business?
Typically, vendor-supplied software includes install and configuration wizards and GUIs that are more extensive and more polished than what is developed for in-house software. This is driven by the need for customer to be able to implement the system without in-depth expertise. While there is certainly value in those kinds of features, are they worth the additional cost? They are primarily an example of the kind of additional development done that is not directly attributable to customer business needs. If those features are of value to the business, why doesn't the in-house development process reflect that value? If the purchased software is perceived as better-tested and more robust than in-house developed software, those cost of those aspects is surely included somewhere in the purchase and support price. Again, if these aspects are valuable enough to enter into the purchase decision, why doesn't the in-house development reflect this value?
All but the simplest COTS software will need customization. While is impossible to accurate assess how much, it is possible to determine what portion of in-house resources go towards needed customizations versus integration with other systems. If the integration is complex and problematic it can take time and expertise away from providing business-critical customization. If the users go without their needs addressed because everyone with any expertise is struggling to make the software talk to the rest of the systems, where is the value in that?
A critical aspect of vendor application customizability is a powerful, well-documented, flexible and stable set of APIs that allow the customer to modify the behavior of the software without introducing incompatibilities and dependencies that cause problems in later upgrades. The question to as
At several places I've worked there's been a consistent subgroup of developers that doesn't use version control. The SQL database programmers and analysts rarely put the DDL scripts into version control. I'm sure there are exceptions, but consistently I've seen them reject it. It really puts the hurt on a project when the application programmers can re-create any prior build or release any time, but can't do anything with it because there's no way to get the database back like it was. Even in day-to-day work, some change that breaks a trigger or integrity constraint that would be trivial to fix if you could roll back to N-1 ends up stopping work while the DB programmer tries to figure out what changed and how to fix it.
As far as I understand, there are two justifications VC-resistant SQL developers cite for this situation. First, that the database can in theory be rolled back to any prior state by mucking around with the transaction logs and unplaying them. Second, that the database shouldn't be versioned, because its current structure is by logical proof the only correct one, and reverting to an earlier version means somehow violating relational purity.
I've seen enough teams that, if you asked the management if they used version control, would answer in the affirmative and indicate the corporate standard (some atrocity like PCVS) SCM software. Ask the people actually writing code, however, and the answer will be no, they don't actually use it. Generalized, there are two reasons. One, the team is too clueless and undisciplined to use version control. The other, the dictated corporate standard is such an awful mismatch for the environment/toolset that the net productivity lost working with it is greater than just using a shared copy and manually resolving conflicts.
It would be a historical cop-out, but CNN could claim something amorphous like "consumer-friendly cable television", which became big around the mid-late 80s, or digital/fiber cable, from the 90s. Either would allow that "and CNN was there from the beginning" self-congratulating angle. It would require some rather convoluted constraints of what is an "invention", since "cable" has been around as long as TV, and in-home cable television is over 25 years old.
Similarly in Firefox, double-click to highlight a word or phrase, right click to get a menu that allows you to search the web. Easily enhanced, invisible.
Incidentally, underscore is a typographic horror. I always make sure to turn off underlining for links.
Slashdot Mirror
If reading source code takes you out of your current objective, you have a write-only view of programming, and that's a problem. Take a look at http://www.spinellis.gr/codereading/
For #4 you wrote about an error hander not checking for EFBIG or ENOSPC after writing to the error log. While it's certainly maximally robust to check that, in modern enterprise-scale systems it's going to be very rare. Now certainly I can imagine some context (say, Martian rovers...) where this kind of check would be much more necessary, I stand by my assertion that it's possible but rare.
The kind of thing I had in mind for novices writing speculative code is more related to what I call programmer-induced feature creep. In the worst cases this code for things that "might be needed in some future" is so buggy as to break the necessary features. Otherwise known as "gold plating"
3. I just knew that someone would bring up the complications of threads. Of course you are right -- but if a novice is solely responsible for tricky multi-threaded code, there's bigger problems! 4. Checking for possible but rare error conditions is robustness, and not what I had in mind. I wish I had a good example. Suffice to say that novices can come up with the most imaginative and oddball ideas about what users might want to do with the program someday.
Mt. Ranier is much closer and much more of a danger if it were to erupt.
Based on the usual sort of writing I see in /. comments, I'd suggest an English degree.
In the last 1960s, Al Bean had been assigned to the Apollo Applications project. He didn't expect to get into space for years, if ever. As it happened, his friend Pete Conrad needed someone to be LMP for Apollo 12, and knew Al was good and was working on long-term stuff that could wait. Al became the LMP for the flight, his first in space, and the 4th man to walk on the moon.
Everyone in the Astronaut training program is looking for their chance to jump the line and get wings, and you never know how might turn out to be the one to flip the critical switch for SCE to AUX and save the mission.
Bean later flew in space again as a Commander on the Apollo Applications mission that became Skylab.
Re: Padding for the inevitable changes.
That comment makes it abundantly clear that you know that it's never right up front. Why pad then? That's either a) cheating the customer, when your estimate turns out high or b) a gigantic risk of your company's profits if you guess low. Do you think the customer doesn't know you are padding? Of course they do -- negotiations up front on scope/price/schedule then end up being a struggle to push the padding one way or another. XP and similar agile methods want you and the customer to honest with each other and admit you don't know how big the thing will be, but that you will start delivering business value from very early, and allowing the customer to steer the project as it goes.
Consider two scheduled airline flights. On the first, the pilot points the nose in the direction he believes is towards the destination at take off and then after X hours begins a descent and landing expecting to be in the right place, and if not, hoping he put in enough extra fuel to be able to make it the rest of the distance to the airport. On the second, the pilot monitors the course, navigates along the way, and steers the plane with the necessary course corrections. He took off with sufficient fuel to make a normal flight, but all along the way he is sure he stays within range of safe landing sites in case of emergency.
Which flight would you take?
Remember the Titans?
Slightly off-topic, but I can cite prior art for use of ISBN numbers to trigger links to booksellers back to the mid/late 90s, when Amazon first created their affiliate program. One of the first Wikis would look for ISBN in the text of pages and automatically turn them into links to Amazon.
What you really want is the Memento Pattern. Intent: Without violating encapsulation, capture and externalize an object's internal state so that the object can be restored to this state later. I agree generally with the other posters who warn against binary serialization and memory dumps. Define a format for writing out the memento object(s) that captures the necessary state but is easily parseable and extendable. A couple of formats that you've probably seen are the windows-style INI files and some kind of XML. There are lots of others.
VIIV
VII = 7 V = 5
75
7+5 = 12
1+2 = 3
75 is 3 * 25
5 is 2+3
VIIV is 525
quod erat demonstrandum, ubi sub ubi
Recently I received a copy of a memo forwarded by a CIO strongly in favor of moving towards buying applications over custom building them. While I can't reprint the memo here, I can speak to some of the points it made and respond to them from an alternate perspective. The memo summarizes one case study within the company of what is portrayed as a successful acquisition and implementation. The application is based on a vendor product and customized in-house to a limited extent. The case study asserts the benefits of the buy decision over three areas -- the technology, the cost, and quality.
In the memo, the author says that a system used by the business is based on a commercial application and claims 90% of it is standard and 10% is customized. There's no detail to justify that number, but suppose the software does 90% of what the customer needs. Left unmentioned in the memo is how much of the application is useful to the customer. In other words, what additional features and complexity is the business paying for with the application suite but not using? It's unlikely that 100% of the features of a commercial application are used by any one customer -- but can the business say it is using even 50% of them? Is that cost effective?
While the vendor's support may help keep the business current with technology, how much are the vendor updates just a way to keep the upgrade treadmill running? How often does the vendor introduce an update where none of the new or changed functionality is useful to the business? What is the cost of being on the vendor's development schedule, and how disruptive are upgrades? Worst of all, what happens when the vendor eliminates a feature that is key to the business?
The memo asserts that there is a significant cost savings to purchasing vendor-supported applications, because the costs of development are spread across all the customers. That's a bold assertion, but looking closer, to what extent is that cost savings eroded by the additional cost of features which are developed but not used in the business? Is the total cost of the software, including those elements useful to the business and those that are not, really less than a solution tailored to the business?
Typically, vendor-supplied software includes install and configuration wizards and GUIs that are more extensive and more polished than what is developed for in-house software. This is driven by the need for customer to be able to implement the system without in-depth expertise. While there is certainly value in those kinds of features, are they worth the additional cost? They are primarily an example of the kind of additional development done that is not directly attributable to customer business needs. If those features are of value to the business, why doesn't the in-house development process reflect that value? If the purchased software is perceived as better-tested and more robust than in-house developed software, those cost of those aspects is surely included somewhere in the purchase and support price. Again, if these aspects are valuable enough to enter into the purchase decision, why doesn't the in-house development reflect this value?
All but the simplest COTS software will need customization. While is impossible to accurate assess how much, it is possible to determine what portion of in-house resources go towards needed customizations versus integration with other systems. If the integration is complex and problematic it can take time and expertise away from providing business-critical customization. If the users go without their needs addressed because everyone with any expertise is struggling to make the software talk to the rest of the systems, where is the value in that?
A critical aspect of vendor application customizability is a powerful, well-documented, flexible and stable set of APIs that allow the customer to modify the behavior of the software without introducing incompatibilities and dependencies that cause problems in later upgrades. The question to as
At several places I've worked there's been a consistent subgroup of developers that doesn't use version control. The SQL database programmers and analysts rarely put the DDL scripts into version control. I'm sure there are exceptions, but consistently I've seen them reject it. It really puts the hurt on a project when the application programmers can re-create any prior build or release any time, but can't do anything with it because there's no way to get the database back like it was. Even in day-to-day work, some change that breaks a trigger or integrity constraint that would be trivial to fix if you could roll back to N-1 ends up stopping work while the DB programmer tries to figure out what changed and how to fix it. As far as I understand, there are two justifications VC-resistant SQL developers cite for this situation. First, that the database can in theory be rolled back to any prior state by mucking around with the transaction logs and unplaying them. Second, that the database shouldn't be versioned, because its current structure is by logical proof the only correct one, and reverting to an earlier version means somehow violating relational purity.
I've seen enough teams that, if you asked the management if they used version control, would answer in the affirmative and indicate the corporate standard (some atrocity like PCVS) SCM software. Ask the people actually writing code, however, and the answer will be no, they don't actually use it. Generalized, there are two reasons. One, the team is too clueless and undisciplined to use version control. The other, the dictated corporate standard is such an awful mismatch for the environment/toolset that the net productivity lost working with it is greater than just using a shared copy and manually resolving conflicts.
read the code... and hope that the class, method, and variable names aren't in Russian typed with Unicode cyrillic characters.
It would be a historical cop-out, but CNN could claim something amorphous like "consumer-friendly cable television", which became big around the mid-late 80s, or digital/fiber cable, from the 90s. Either would allow that "and CNN was there from the beginning" self-congratulating angle. It would require some rather convoluted constraints of what is an "invention", since "cable" has been around as long as TV, and in-home cable television is over 25 years old.
Time for another name change. Just call it "teh intarwebs".
But when will they ever have native OS X support?
Similarly in Firefox, double-click to highlight a word or phrase, right click to get a menu that allows you to search the web. Easily enhanced, invisible.
Incidentally, underscore is a typographic horror. I always make sure to turn off underlining for links.
> People aren't going to be lugging around terabyte-sized password database files.
Not this year, probably not next year. Sooner than you probably expect, though.
Too bad the author of the story didn't see fit to mention Ward Cunningham, the inventor of wikis.
You'll get the dreaded Blue Street Of Death
Oh great, now chat will get slashdotted.....