And, I'm a tech dude: 2xCat5e and 2xRG-6/U structured wiring throughout the house (soon to be sold), satelite multiswitch, dual twin-LNBs, HDTV, you name it. But, I don't get the idea of a box that ties me down to one location, i.e. a media room, which requires a subscription service.
Sure, sure, I can pause and rewind live TV and have it record what I'm likely to like, and it gets rid of all those messy tapes. But, ya know, what? I can take that tape and shove it into any VCR in the house... or any other VCR, if mine break. While that's possible with Replay units, it's kinda klunky still.
Here's what I want: recordings in my inbox. Well, perhaps not emailed to me via the usual route, but dumped to some server in my home from some local device with a cable or satellite feed. But, I want the flexibility to deal with them as I would any other data in my home: stream them to whatever playback device I desire, make archival copies, etc.
I know, DRM prevents this. And it's true, but it does so in a far to heavyhanded way -- I want the days of fair use, and I'd accept mechanisms to constrain that use to being far, but not DRM as presently proposed or implemented.
As for a program guide subscription service: Unbundle it! Tell me how to tell the box what to record and let mo choose the service that will I can subscribe to to get that information in the necessary format to seamlessly integrate with the recorder. Yeah, if that means the recorder has to be sold for it's actually retail price, if I don't accept the manufacturer's subscription service, so be it.
Like many, I recently lost my software development job. In my case, an H1B from Canada, this means selling my home, and returning to Canada. Contrary to popular belief, you can't hire H1Bs if you've been laying off (or even firing with cause) Americans (though, no doubt, some companies operate illegally in this regard). Having an American-born son means nothing (except that theoretically, DCF could have ordereded him to remain in the U.S., for his "best interests").
With hard work, I managed to find another software development position, though somewhat different to what I had been doing: digital television graphics chip automated testing instead of telecom (which is really sick these days). The point is that tough times require flexibility -- automating testing systems had been a core responsibility of mine, in addition to development, and I can leverage those skills into an area of personal interest, without "real" professional experience.
In that regard, the 20 years professional experience helps, rather than hinders: there's lots about test automation that can be leveraged to different problem domains. Still, many would-be employers cared more for modern skill-matrix check-marks, than a proven ability to think ("No, I don't really do Java, but I have pulled some servlet code out of a nasty pickle, when necessary.") and didn't give my resume a second thought. Somehow, I got the impression that I didn't want to work for an organization with that attitude.
If I were to give advice to the "aging programmer", say 40+ like myself, it would be to stay as current as possible (at least conversationally with the latest fad, and preferrably having played with it), try to go the extra mile to be indispensible where you are (performance wise, not necessarily skill wise), and remain flexible in looking for new opportunities. Above all, try to not get depressed -- that fuels a nasty downward spiral.
This Christmas would have been dismal. I was out of work since October (well, I knew since September, and traded severance for dismisal for immigration reasons), except I got a job Dec. 24.
Money is still tight, but for the past month or so, I had been ignoring the Salvation Army guy with the kettle outside the local Target store, and on Dec. 24, I slipped US$20 into the kettle.
O.K. So I always wanted to be able to afford to slip a $100 bill in there, but I figured this was a reasonable compromise between my family's welfare, and that of those less fortunate than us -- umemployment sends that message home pretty hard.
As for our plans, we are packing and planning a move. Sure, the $20 is a drop in a bucket, but I figure better that than nothing. Perhaps someday, I will be able to donate more, I had already donated a car to charity this year, before I lost the job.
Some will think me generous, others cheap. Frankly, I don't care -- I do not give for the sake of others' opinions. I do what I can, given my nature.
One person whispers a short phrase into someone's ear who then passes it along in the same manner to another person, until the phrase gets transcribed by all people in the room, and the oft-hilarious result then disclosed.
I've often thought software development is like that.
Unless you're contracting directly with the customer, and note the requirements in his/her words, translating them to a technical equivalent (and, of course, translating back, and making sure you got the jist of what he/she wanted), you run the risk of these translation problems.
Often, such insulating layers are placed between well-meaning programmers and the customer to make sure they don't try to deliver more "work" than what the customer is willing to buy. This gets difficult because the programmer where the buck ends is expected to make the customer happy, but to spend the least amount of time possible on it, so that he/she can be assigned to the next project.
I've always thought that was a bad idea. Novice programmers' enthusiasm can be restrained by senior project leaders who might actually be the contact point with a customer -- they're called "systems analysts" for a reason -- the supposed ability to translate human-speak into technical requirements and estimate the work to be done.
In an ideal world, this estimate would be returned back to the customer via sales and a human-speak description of the work to marketting so they can get a feel what piece of it might be reusable on other projects and to feel the pulse of market desire.
More likely, much of this initial analysis is done by people not qualified to do it (sales and marketting types, though technically savvy people do exist in such roles), and critical customer requirements are either lost or not questioned.
I've been in situations where a customer's technical team rejected outright our technical proposals purely because of miscommunication across our respective management hierarchies. I've also been in situations where such miscommunication finally gave way to both technical groups getting together to convey an understanding of what's really wanted, usually after wasting much time and money. Often, in such meetings, one can almost feel the light bulbs finally turning on above the heads of those responsible for the confusion: "Oh! So when you said you wanted it ON a hard disk, you meant INSTALLED on the hard disk in the system, say, from a CDROM, and not DELIVERED that way!!" In all fairness I can see both ways being legitimate software delivery systems (the latter particularly if you're serving as hardware integrater too), but it is important to recognize the ambiguity and resolve it early.
What I've found works is a close technical liason to define the work to do, but, of course, no programmer delivers anything except through official channels, which are gated by the money stream.
I never understood why was it so much easier to use templates and rely on the fact that the class has said compareTo method than it is to then declare that your class implements interface Comparable for example.
To answer your question, if you don't mind a C++ focus, may I suggest that you read Andrei Alexandrescu's "Modern C++ Design", Addison-Wesley, Boston, Mass., 2001, ISBN 0-201-70431-5.
Among other things, it offers a way of facilitationg the explicit coding of design pattern implementations.
Sigh,
So, FCC is now goimg to be supporting the electronic industies in Korea, Japan and China?
Sounds like a great win to the VCR manufacturers OUTSIDE america (since from the article it says that it will be illegal to make vcrs without the devioce o' doom IN AMERICA). I mean, patriotism in America is pretty big, but will people buy handicapped devices just because they are made in usa? I doubt it. You'll buy the properly working vcr's from outside
I'd think that it would be illegal to import such VCRs because they would be circumvention devices. Thus, I can't see this chanelling American demand to foreigh suppliers, as you seam to imply. It would mean that there would be no demand for such crippled VCRs outside the U.S. So what? Most likely, the crippled VCRs would be foreign-made anyway. Just another variation on the basic product.
This is not the same as the issue of limiting export of American-developed hard cryptography: there, such limitiations were silly because foreigners are quite good at developing their own crypto, and would have no need for crippled American versions. That was an example of legislation which was ineffective in controlling access to crypto technology outside the U.S. The present case is an attempt to control access to technology within the U.S. - arguably easier to accomplish when it comes to hardware.
Besides, it is the only language AFAIK where "PERFORM INTERCOURSE VARYING GIRL FROM WIFE TO MISSTRESS" is legal (however, IIRC, one can't have a VARYING and say, "UNTIL TIRED" clause in the same statement). Oh well.
It does rot the brain, though. Kind of like Javascript -- a language so tied to a particular application that it's difficult to use it for general purpose programming. Of course, it can be argued that it was never intended for general purpose programming. "COmon Business Oriented Language"... get it?
I still chuckle at the time I was doing a short stint for a company that received some data from a client for an application we were developing for them... no one could decode it, until I realized it was probably a COBOL COMPUTATIONAL-3 encoding. Sure enough...
ok, so in a sense the broadcasters own the content they broadcast and therefore can somehow manage to get a law like this passed.
Well yes, but there are several problems with laws like this:
1. They suddenly make an assumed legal activity illegal. People have come to expect that they can time-shift broadcast TV with VCRs. In fact, their right to do this has been upheld in the Sony v. Betamax case. While this can change, it hardly serves what the public wants to do with the content it receives.
2. Because of history (see 1, above), there is something that seams fraudulent about suddenly depriving people of a capability they had. I doubt that this new "feature" will be widely advertised.
3. Criminal laws are enforced at public expense. If it is impractical to enforce the law (i.e. the technology can be easily circumvented), expect either increased taxation to fund the "war on time-shifting" or selective enforcement.
don't you own your house?, what about the broadcasted waves that go through your place?.
can't someone make it ilegal to broadcast copy-controlled content through his/her house?.
Difficult. Yes, you own your home, subject to eminent domain, zoning laws, and HOA covenents. But, your elected representatives explicitly permit broadcast television. About the only thing you could fight are excessive radition levels (i.e. someone getting a broadcast license and putting up a tower right beside your home -- but that doesn't happen).
In the case of cable, since you permitted the installation in the first place, you'd have no case.
i don't live in the us, but if this gets passed, it probably will spread to third world countries
such as mine who are always passing laws in order
to get more money lent.
Dunno. The dynamics aren't the same as with, say, the drug trade. I'd expect that similar laws would get passed by pressure from local content owners for the same reasons as in the U.S., rather than because of pressure from the U.S. government.
I don't know if cookie-cutter components for houses is the way to go, at least not at the level of making major changes. For me, having owned three houses, and soon (due to unemployment) to move into a small rental place (until I can s/un//), the issue hasn't really been one of layout, or style, but basic space, and utility.
Over the years we (myself, wife, two kids, a cat, and a ginuea pig) have accumulated the usual amount of "stuff". Facing a move, we're getting rid of stuff we don't really need: donating old books to the library and either discarding or giving away junk (and yes, that includes a lot of computer/electronic related junk, on my part). But that got me thinking: "Why have all this stuff in the first place?"
Of course, as a geek, I've always wanted to serve music and movies from a central server to client machines around the house. Recently, I've been able to accomplish this, but the real motivating factor lately has not been the "neetness" coefficient in doing this, but the pleasure in not having to have "media" cabinets in entertainment areas, with increasing amounts of media (CDs, DVDs, and legacy audio and video cassettes, and vinyl albums) that threaten to overflow the capacity of the cabinet -- in my younger and perhaps more foolish days I had a solid-oak and granite cabinet designed, with a modern look, to accomodate 240 CDs, 90 cassettes, and my B&O Beosystem 5500. Looks great, even 15 years later, but what happens when I get CD #241? At least now, it makes sense to archive the actual media, possibly refreshing the content to more dense media over time, serve the content from hidden servers, who's capacity can grow with technology, and generally upset the ??AAs because of the unscrupulous applications of the means to do this.
Homes appear to be designed to accomodate "stuff", more or less depending on how much material wealth one has. My take on this is that they should be designed to reduce the need for "stuff", in the first place. To be sure, proper networking to accomodate information and entertainment data is part of this (heck, even my bills arrive electronically, and I get an end-of-year CD from PayMyBills, instead of ever-increasing file storage), and a large part, and a lot can be achieved with a "data" headend and appropriate wiring in even a modest home, but it's just the start.
Clothing, kitchen, and garage storage has got to be among the most inefficient use of space there is. Why do we need wardrobe cabinets and dressers? Why not simply provide enough closet space in bedrooms? Or "bench"-style storage, kind of like Captain's beds, but all around the room walls, modular, and the right height to put things on, much like a dresser. Wouldn't take more space than a dresser, and, most importantly, it would mean that you don't need to own a dresser for each bedroom. Modularity in such units (rather like kitchen cabinets) would be most welcome. If you want to go all out, eliminate the bed foundation: build it into the room, needing only a mattress and box spring, with sufficient modularity to accomodate single, double, queen, and king. Unless you really want your bedroom to be a second living room, with a certain "style", a bit of a "cookie cutter" look, if it saves on the need for furniture, would be great -- you sleep there, after all. Personalization can take the form of wall hangings (posters, paintings, photographs, LCD or plasma displays, etc). The place for style and traditional furnishings, IMHO, is in the more public areas of the home: living, dining, and family spaces. Personally, I'd be happier with smaller, more functional, bedrooms, with the reclaimed space added to the other areas of the home.
On to kitchens.
Cabinets... can't have enough kitchen cabinets. Why? Because there's no standardization when it comes to kitchen utensils and plastic storage containers. Take a cutlery drawer: one usually has a plastic insert that holds forks, knives, table spoons, teaspoons, forks (regular and desert). All the odd-sized "infant/todler" stuff, garlic presses, tea infusers, chopsticks, hand can/bottle openers, etc. get dumped into the "miscelaneous" part of such an organizer and invariably overflows into the reset of the drawer. What a mess. While the basics are taken organized, the rest piles up.
There should be a "standard" kitchen set, designed to be stored in a modular insert for a standard kitched drawer that accomodates 95% of the most common kitchen items. Oh sure, you'll always have the rarely (or less-rarely if you like to cook) used implement, but there is something wrong when a kitchen drawer insert's largest part is for miscellaneous stuff, and it's too small.
Plastic storage containers. The round ones really waste space, and the square/rectangular ones don't fill cabinets to a decent packing density. Cabinets, fridges, and plastic leftover storage containers should come in standard sizes (the first two probably do, but that doesn't help the latter). I'm thinking like 19" racks with 1-3/4" spacing per "U" -- except, call them "K"s, for kitchen: you'd have 10, 12, 16, 18 "K" cabinets in various widths (multiples of, say 4-1/4") to accomodate 1, 2, 3, 4, etc. "K" storage containers in multiples of the same standard width. Drawer inserts would conform to this standard too, so you can have the extra cutlery for 8 stashed in a cabinet, perhaps.
Kitchen cabinet shelves: make them slide out, dammit! And fit in the dishwasher (being dishwasher safe, of course). This is probably most important for pantry shelves, which accumulate bread, cookie, sugar, salt, pet food, and other debris, but, as we all know, the pantry overflows to an extra cabinet (at least it does for cat food in our home). Naturally, they should be adjustable-height. Modern kitchen cabinets come close, but, while removable, and adjustable, they are not designed for this to be done on a regular basis. Oh, and while we're finishing up in the kitchen, standardise the sizes of canned goods to match the pantry/cabinets.
Laundry Rooms. Every house needs one. My first two had just had the washer and dryer in a corner or closed off section of the basement, and the last one (built recently) actually had a separate small room. The latter works well, but gimme storage space for all the cleaners to keep there (not just detergents). Two storey homes really need a laundry chute -- bring it back. And, oh, a dumbweiter to take the folded laundry back up. As long as we're on the subject, why haven't we solved the problem of the bursting washing machine hose, huh? Yes, one should always turn off the main taps when not in use and not keep constant pressure on the hose (or rather the washers, which are what tend to give when you are 3000 miles from home), but who remembers to do that? (Well, I do, but my wife doesn't./me ducks). Why the @#$%^$# don't washing machines have standard control signals for fail-safe water solenoid-controlled valves instead?
Living/Dining/Family rooms: here's where the style of the home/occupant should show and really be the only place where "furniture", in the classic, non-modular sense, should be needed.
Garage/storage: why ultrasonic bumper ranging devices aren't standard, with large LED distance readouts, or at least red/yellow/green "traffic" lights, I dunno. I guess people really do manage to park their monster vans with 1" to spare front and back, without difficulty.
Interior walls: repeat after me: should be movable. Within the limits of structural integrity, most interior walls, separating sleeping areas from each other, and from other living areas, should be removable. Yeah, this is asking a lot, espescially if it is to look O.K. without any ugly attachment points on the walls/floor, ceiling. But it would be real nice to change a 2 master, 3 bedroom house, into a 1 master, 4 bedroom house, when the second kid comes along.
Of course, these are just my thoughts, off the top of my head (or, depending on your opinion, pulled out of my a**), but I definately think there is room for improvement and some degree of modularization/standardization in the house building industry.
Ya know, that's all it is: bull shit, crapped out by marketting types to sell the "next greatest thing".
Certainly, there are a variaty of ways to distribute an application, when you start to have real compute power at the human end of things, but they're all variations on a distributed processing theme, conveniently placing a "tier" at an architectural point with clean, simple, and few interactions with components at another tier. Hence, three-tier and n-tier applications: they're just particular distributed "sweet spots" particularly appropriate for certain large classes of applications.
In the old days, if we even considered such distributed systems (requiring a PC on a desk, instead of just a terminal), we coded all the protocols, marshelling schemes, and so forth ourselves -- it was an in-house thing. So, yeah, all such distributed applications look the same, from that perspective, the way that all large C or C++ applications "look the same", if well-designed.
But, as particular distributed mechanisms meet large "sweet spots", such as a web browser/server split, they're pushed as the definitive "answer" to man-machine interaction.
And, just as quickly, or shortly thereafter, the shorcomings of a particular popular distributed architecture split become apparent, and the next "model" is pushed as the definitive "answer". The fact that it is tuned to a different class of problems is generally lost on those flogging it, and those buying it. The rest of us just kind of look at it and say, "yeah, so?" -- after filtering through the buzzword muck.
Now it is true, that, as client-server models (and all of these are just that, really) mature and are pushed into use, they are strained to the limits of their scalability, and two-tier architectures give way to three-tier architectures, and so on. So the new tunings offered by the "latest" architectural split does serve to solve new problems, but that in no way invalidates the fact that the "old" architectures did a splendid job of serving to solve the "old" problems.
The frustrating thing, from the perspective of someone like me, having worked with all sorts of distributed systems for close to 20 years, is the notion that one such architecture is sufficiently different from another that the "old skills" are now obsolete: client-server techniques do not transfer to three-tier architectures do not transfer to, what's the buzzword?, oh, yeah, "Web Services".
While the interfaces are new, and the implementations of the various components need to be picked up, a seasoned architect will look at them an say, "yup, that should scale the way we need". However, there is this notion that this can not happen quickly, and new "experts" need to be hired to replace the "old" experts.
Funny, most places don't get rid of their "if statement" C++ programmers when they need "while" statement-, or golly gee, "function call"-programmers. Understanding of standards particular to a given architectural model may be important, but it's such a small part of rolling out a working system, that any competent software engineer can deal with them.
Don't make the mistake a former employer of mine made: contracting out some servlet code to "Java experts"... that had no clue about threading issues because, while they "learned Java", they knew nothing about multitasking issues. Hint: those that understand the latter generally adapt to a different language faster than those that know a single language adapt to other than basic computer concepts. And so it is with buzzwords designed to obscure the obvious.
I'm pretty sure "Joe OfficeSuite" doesn't spend much time producing documents in more than one format, so where's the benefit?
Publishing for paper and on-line versions is getting increasingly common. Furthermore, if you are producing paper versions in a big way (i.e. using the services of a printing company), you probably need to produce output in an acceptible interchange format, with split color layers, etc. (Oh, FrameBuilder did that SOOO well!)
Yeah! Just ask Netscape and Corel how unlikely a company is to lose their bread and butter if they start out with a huge market share lead.
The point is noted: in a free market you always have to watch your back for the competition, lest they sweep by you. However, there's a bit of a difference between incumbent word processors and web browsers (Microsoft vs. Netscape).
The word processor requires a significant investment to learn, if you're going to use it to produce documents with any structure or complexity (cross-references, indexes, tables, consistent style, etc.) There is no such learning curve for a basic use of a Web browser. So, abandoning one for another is a lot less painless than migrating from Word, to, say, FrameBuilder (which, IMHO, is a programmer's and publisher's dream to use).
Thus, once an investment is made in something complex, particularly when its utility is enhanced by network effects, it's difficult to change.
Now, I hear you all screaming, "WordPerfect!". Truthfully, Word offered more elaborate formatting control, to make the transition from a simple "text formatter" to a "word processor" worthwhile -- providing greater functionality (and locking in a commitment to greater complexity). Yes, WordPerfect caught up, but it was a question of too little too late, espescially with Microsoft's intergration of their office suite components.
Now, there is still hope: an XML-based standard document format can offer something that is difficult at best to do in Word: separating style and output from content: a single document could end up rendered in PDF, HTML, plain text, or conceivably, Word formats (though RTF is more likely than Word, and importable into same, IIRC).
Yup, everything on 100BaseT, or even 1000BaseT (GigE Copper). Sure would simplify home cabling, wouldn't it?
Ever wire a house for voice, video, data? Well, there's a rather standard way of doing it and it involves two four pair cables (Cat5e, generally, though in the "old" days, if you were penny wise and pound foolish, you'd run one Cat3 and one Cat5, or worse, one quad "Jake" and one Cat3), and two RF cables (RG-6/U, preferably quad-shielded).
One of the quad-pair is used for data, the other for phone (some of the more complex phone systems actually need all 4 pairs); one of the RF cables is used for distribution from the headend, and the other for modulated distribution back to the headend, to distribute your DVD throughout the house.
It's supposed to be the most cost-effective way of doing things: cheaper to RF-modulate an analog signal than do real-time MPEG2 encoding to stream over IP, right? Same for the phone stuff, though, as the original query hints, not out of the realm of afordability to do it over IP. And all that cable! Do you know how thick a bundle of 2xCat5e and 2xRG6/U is? About 3/4-7/8 inch. It's a real pain to retrofit into an existing house. Been there, done that. Wireless data networks start to look real attractive.
Now, you can get products like SpeedWrap that add an extra jacket (and some even include Fibre), which makes deployment a bit easier, but the cable costs about double what individual cables do (still, if you're paying for installation, it can be worth it).
Yeah, it would be real nice to do it all over IP, and thus, one 100BT or GigE network connection.
I've often thought of a "per-room" interface box, with network in, and telco, intercom, digital audio, and video outputs and possibly digital audio and video inputs. The idea is to interface to legacy equipment (like standard handsets, intercom speakers, stereos, TV's, etc), with one little wire snaking back to the headend. Computers, of course, connect directly to the network. You might want to splurge and have several nets: entertainment, data, and DMZ data. Such things would be a real hacker's dream to design, build, and deploy.
The kicker, of course, is cost. A phone and a bit of wire is way cheaper than this kind of tech, which requres, effectively, a fairly powerful computer in each room to be networked. Gigabit ethernet switches don't come cheap. Start running MPEG2 video around your home lan and the ??AAs will be all over you for "infringement". Still, Moore's law being what it is, in about ten years, such things could be made as cheap as doughnuts.
Yeah, this went off-topic, and didn't provide any tech solutions for IP-intercoms, but it does warrant examing the bigger issue of putting all of a home's digital and digitizable traffic on a LAN.
If you organize your nodes in a deBruijn graph, you get log2(n) hops max between n nodes.
To do this, you only need four interfaces per node (actually, you need two transmit and two receive, so could get away with two, but let's stick to four so we don't have to hack network layer code).
Assuming you have 2^n nodes, you number them from 0 to 2^n-1. Node n is configured to transmit to nodes 2n mod 2^n and (2n+1) mod 2^n. By extention, it receives from nodes n / 2 and n / 2 + 2^(n-1).
This lets you get a message from one node to another in at most n hops with 2^n nodes and four (or two) nics per node.
I understand what you are saying here, but I do have to say that there are limits to this philosophy. There is a certain amount of hubris in the belief that because you know OO you can pick up, for example, J2EE in a week or even a month. For a while on a project you are either going to be moving very slowly and learning on your own, or will be moving slowly while learning from others (thus slowing them down).
The point is noted, and I can only write from my own experience with picking up new things "on the fly": my history has always (though past performance is no guarantee of future results) been one of going from novice to expert, and exceeding the skills of the resident experts, in short order.
Certainly a rich and broad inventory of classes with which to attack a problem takes time to learn. But again, I have often found those who know the inventory often can't judge the applicability of a particular architectural choice for lack of an understanding of implementation details that "leak", i.e. performance, memory footprint, etc. Generic skills come in handy here.
If I were to seek a position where Java was the primary implementation language, I would consider an intermediate development position, and certainly not an architectural role, at least not right away. But, what's upsetting is someone not realizing that over a decade of OO and expert C++ work, along with a demonstrated track record of adapting to new technologies, APIs, etc. isn't even considered superior to utter novice level with a new or different technology. The vast majority of the skills repertoire does transfer.
Yet, when something goes wrong with the underlying technology they are unable to properly fix their product because all they know is some basic java or VB and they don't understand anything about sockets or big-endian/little endian byte alignment issues. It's no wonder todays software is huge and slow and doesn't work as advertised.
Oh yeah. Definately.
I'm one of the cranky, grizzled, old farts (well, 41, which, in this biz, is old). The early serious work I did involved Z80 assembler for X.25 PADS, switches, and mobile radio modems. Even code a FEC to combat Raleigh fading for a radio modem in a police car? We hacked practically to the bare metal 'cause that was the only way to get acceptable performance. We were few and far between, compared to the Cobol weenies that took "Business Programming" in school.
Of course, over the years, one moves from straight assembler, to C, to C++, and instead of rolling one's own kernels and schedulers, starts to use offerings like pSOS, and MQX, for real-time embedded apps, and Linux and FreeBSD for time-constrained work. And, one leverages language, and library, abstractions because they make your development life easier and more productive.
Then, something doesn't work. And, guess what? Us "old farts", who either understand the underlying implementations, or can make an educated guess about them, are often the only ones who can find and fix the problem. This skill often extends to areas where the abstractions are foreign: I once singlehandedly repaired a bunch of Java servlet and RMI code developed by an outsourced "Java expert" team, despite being quite the Java newbie myself.
The problem was simple enough: it was a thread-safety issue within the servlet engine, and "smelled" that way, from the looks of how it was failing. Damned, but I know all about those kinds of dangers and instinctively code defensively when it comes to multi-threaded code. The actual task of picking up enough Java to understand the intent of the code and the APIs being used, was no big deal.
I take that kind of skill, to drill down through the abstraction, and find and fix the problem, for granted. I joke, "That's why they pay me the big bucks!". I have found this skill lacking in many new graduates and people entering the field, having had abstractions and the language du jour rammed into their heads instead of basic computer principles: perhaps one in ten that I interviewed can sort their way out of a paper bag. That saddens me.
Yet, despite these shortcomings, it appears to be specific abstraction knowledge that's in demand, and not an inherent understanding of how the systems work their magic. To use an analogy, yes you need a chauffeur to drive you from A to B, but you also need a mechanic when the car breaks -- HR people are hiring chauffeurs on the assumption that cars never break or are abused.
If you need people who can adapt to whatever the abstraction of the month is, and drill down and understand the mechanics of the underlying implementations, call me. I'm looking for work.
I think you're missing the point of my reply. You said 'buzzwords' and SQL and Java aren't buzzwords. XML and.NET are buzzwords (ie: currently in vogue and "cool").
O.K. I think I get the point you are trying to make, though XML and.NET are every bit as much technologies as Java and SQL, just new and thus "sexy", and prone to buzzword mining in resumes.
Where I criticize something as a "buzzword" is when an inappropriate weight is given to it as a skill, when compared to the general skill really desired: OO in the case of Java, query languages in the case of SQL, and structured data in the case of XML -- there are other examples of these skills and they should carry over: C++ experience should be a good fill for Java, evidence of handling structured data for XML, and experience with heterogenous systems interworking for both XML and.NET. That, and a proven history of adapting to a different flavour of the "same old thing" in record time will often be better than someone with recent Java and SQL Server experience as the only OO/Database expertise they have.
You are right about Smalltalk being single inheritance, I think, but, IIRC, it has a rich dynamic type system that C++ and Java can only dream of. As for multiple inheritance, I suppose multiple interfaces can work as a proxy, but then you have the whole member function virtualization overhead for them no? C++ is superior here in that you can have implementation composition without that extra indirection. Whether that matters in practice, is, of course, debatable: there is a whole school of thought that anything that can be done at compile time should, as a matter of optimization, but, OTOH, this stiffles dynamic run-time extentions.
Just a nitpick here but SQL is hardly a buzzword. Its been around forever. Java is way past the buzzword stage as well. You want buzzwords you got XML and you missed.NET.
Point noted re. SQL, but it's just a query language. Anyone with database theory should be able to pick it up in no time. More to the point, anyone who's used a more typical programming language should have no problem with something as simple as this, syntactically (though, it is also baroque in the same way that COBOL is).
As for Java, sheesh! What matters should be OO methodology and an understanding of n-tier architectures (which is but a physical manifestation of the former). Java is an implementation detail with certain nice cross-platform attributes (like client-side validation off-loading, etc.)
Perhaps I'm a bit of a crank about this, but having been in the position of implementing code to desirable "common", if not standard, APIs in an embedded environment from scratch, specific API knowledge does not strike me as it should be a major differntiator -- picking up a new API and language is trivial by comparison.
Of course, if Java is your first OO language, and you're learning the principles and practices of OO design, development in a heterogenous environment, good Java skill matters, but it's not really the Java you're learning, it's the nature of programming in that environment in general.
So, I'll still rank Java in the buzzword camp. The language matters far less than the overall architecture and really just represents a means to an end.
Could the same argument be made about C++, or other OO languages, like Smalltalk? Perhaps, but, unlike Java, they are richer in terms of the native OO concepts they support: multiple inheritance for one. Java scales back on a lot of these things (simply parsing C++ is, admitedly, a bitch), and adds more practical facilities (garbage collection and native multithreading) useful in a particular set of applications.
As for XML, and.NET, so what? Yet another interchange and serialization format, and marshalleling scheme. Sure, there's a whole bunch of support code around the technologies, but it's still just a different way of doing the same old thing. RPC/XDR was the big thing in the Unix world way before XML, and more efficient too.
I dunno, SQL, Java, and XML just give me an, er, COBOLish feeling: programming for non-programmers with a business app bias. I suppose we can afford the cycles to be inefficient for the sake of rapid deployment and easy inter-subsystem debugging, but the argument stands that if you could hack the "older, less friendly stuff", this new tech is not a big deal to pick up. Focusing too much on the most recent specific implementation technology of rather old principles does strike me as buzzword mining.
How do you know if something is the right tool of for the job if you don't really know anything about it?
It is possible to know what something is used for without having to know exactly how to use it for that.
For example, I can make a solid reccomendation dropping Tomcat in place of Alaire's JRUN as a Java servlet engine, without knowing how to configure Tomcat -- that comes quick enough. Whether this is a good idea depends on an evaluation of Tomcat's stability and speed, whether any quirks of JRUN are being exploited, and so on. None of that really requires "three years experience" with Tomcat.
Now it's true that experience with the tool in question helps answer those kind of questions, but it is not the only way to get those answers with an acceptable degree of confidence.
Indeed, remaining focused on the tools with which you have expert knowledge often leaves you narrowminded when it comes to "out of the box" thinking to deal with new problems.
For example, we had a requirement, on a distributed internet test platform, for an administrative interface. As usual, implementing this kept getting put off and put off until it really became a critical path issue, which no one considered. So, we had the proverbial "zero time" to implement an admin interface, secure in the public internet. Bad planning? Bad management? Perhaps, but shit happens, and what separates the men from the boys is dealing with it.
Without knowing much about Apache or Linuxconf configuration or extention, it nevertheless was obvious that using Apache to proxy an SSL session to linuxconf's web-based interface would get the job done, with little "real work" providing linuxconf backends for our unique copnfigurable components. It may not have been the most elegant way to get the job done, but it worked, proved secure, met the requirements, and was done in time.
Now, do you think any of the "Apache" or "Web" experts knew anything about this? Nope. They had no clue where to start. I knew nothing about the specifics but was confident that these components could be glued togehter via configuration magic, and perhaps a bit of custom code, and a google search confirmed these suspiscions.
You could argue that webmin might have been a better choice, and without panic, a better analysis could have been done. But, so often, the ability to work with less than ideal specs and data is what keeps a project on track.
As the guy you'd be seeing who does the interviewing, here are my five tips for a long and interesting career:
So, hire me. See sig.:-)
1. Do whatever YOU like, but do it well.
Some flexibility is necessary. I'm not crazy about Java, or scripting languages, for example. Of course, I come from an embedded background where you squeeze every last drop of performance out of your resources. Not everything has to be blindingly fast, and there is something to be said for rapid deployment. As much of a development geek that I am, I have found pleasure in streamlining build environments, generating test infrastructures, and producing customizable installation media. Even "mundane" tasks can be made superb with the right attitude.
2. Only work for employers that you want to get up in the mornings for.
Aye, though I'd augment that by saying, "Only do things that you like getting up in the morning for." -- the employer might be a bit of an ass, but the job can still be fun.
3. Dedicate at least 10% of your "work" time to professional development, even if you have to pay for it. Go stale = out of job
That's been my mistake. I never really got into the whole Java, J2EE, enterprise "thing", dealing with it when necessary (and damn well, at that). Also, it can be difficult to find that 10% when work time ranges from 60 to 120 hours a week to correct mistakes made by others -- the tragic flaw of having exceptional troublshooting skills.
There's a tendency to not "train" after having seen a lot of different, but similar, systems, because a good S/W engineer will pick up the required skills as necessary without wasting time on traning that may or may not prove useful. However, future employers like to see "training".
In an attempt to correct this oversight on my part, I have been spending some of my free time with "buzzword" technologies like SQL, XML, Javascript, and Java -- though the tendency does remain to think, "I'll pick this up when it's the right tool for the job and not sooner."
The difficult is that many employers will not believe that you can actually do this, even with a history of pulling off "miracles". Sell yourself too hard and you come off as arrogant.
4. If you're not having fun, leave. Life is too short to put up with crap.
Alas, one has to eat, and leaving is not always practical. But, the sentiment is noted.
5. Don't choose the boring staid job unless you want to retire. Be different. Work for Microsoft*.
Indeed. The best time of my life was working for my last employer, and optical router startup. Sadly, I got caught on the wrong side of a 20% cut to make VC capital last. Still, smartest bunch of people I worked with.
OTOH, after a while, one starts to think, "Ya know, why not take all one's savings, buy a cheap house in the country outright, and 'retire' to give the people at the local Rat Shack blank stares (or, if they're clueful, a surprise of knowledge).
If you're after buzzword compliance (j2ee,.NET, etc), read the other 500 posts. As you already know, they mean nothing in 5-10 years. My tips will last a lifetime.
If more people live in the cities, why shouldn't their concerns get proportional weight? What gives a person who is surrounded by big fields more importance than anyone else?
Yes, that would be the democratic thing to do: one person, one vote. Period.
However, areas with high population densities would swamp the will of areas with lower population densities to the point that the midwest would probably not count at all. In that case, why bother being part of the Union?
Preservation of the Union of United States is one reason why representation is not purely democractic, and the President requires a wide degree of diverse support, even if the quirks of the Electoral College system mean that he or she does not get a majority of the votes cast. These same quirks tend to favour two party systems and make it extremely difficult for third parties to get a foothold. From a stability standpoint, that probably isn't a bad idea (even as I am a staunch third party libertarian supporter).
Ideally, these quirks would not matter, since the President heads the administrative arm of government, and not the legislative one, comprised of the Congress and Senate. However, the past 100 years have seen an increase in executive powers that likely exceed a healthy limit for a purely administrative head of government.
I am a C++/C/Assembler embedded telecom geek, for the most part. I don't really do things like Apache, Java servlets and applets, and deal with backend databases whether they be mySQL, Postgress, Sybase, or whatever. Nevertheless, I have been exposed to them as part of my day to day work: someone has to deal with the front and back-ends for data that our embedded systems acquire.
Of course, with close to 20 years work experience under my belt and graduate degrees in Computer Science, you'd think I should be able to adapt to anything and pick it up in a hurry: I know enough about customs and trends in programming language syntax design and the way distributed systems are architected, as well as issues related to inter-process and inter-machine communication.
Recently, I found myself looking for new work.
It's a tough market, but I'm adaptable, with a proven track record, and willing to take on n-tier ecommerce applications if I have to, despite really liking things like silent set top box designs that suck and decode MPEG2 video from local or remote servers. So, I start looking.
Java, Java, IIS (ugh!), Apache (well, O.K.), PHP (yea, looked at it), mySQL. No big deal, right? C++ and OO skills in general port to Java (it is a simpler language after all), and hey, once you get the code classes and a bit of Swing or AWT, you're rolling. A week, tops. mySQL requires a quick study of SQL syntax and the particular ideocyncracies of that implementation. Yeah, I've configured Apache a couple of times and even set up an HTTPS to HTTP proxy within it for a linuxconf HTTP administrative backend. Kinda cool.
"But, you don't have any real Java experience," I start to hear, more and more frequently. Well, no, I don't really do Java -- I use the best tool for the job, and if Java fits, I use it. It just rarely was appropriate for the domain I worked in (real-time embedded telecom and data acquisistion). But hey, need something client-side in a browser, and yeah, Java is the ticket (unless it's so trivial that Javascript will do -- where's my DOM manual, again?). So? I didn't do Python either, but that didn't stop me from extending Red Hat's Anaconda, did it? And what about the time I had to handle a bunch of regexp matching -- perl was just the ticket. Someone embedded tcl in something we once inherited, so, time to pick up tcl.
Of course, no one believes that anyone can be so versatile, except other people equally versatile. Almost certainly, this excludes HR people. Otherwise, they wouldn't be in HR, would they? They'd be along-side designing, and developing the future.
No, I don't really do Java -- I just pick up the pieces when the outsourced "experts" forget to synchronize appropriate members of the objects they have living inside a multi-theaded servlet engine (why we paid big bucks for Alaire's Jrun instead of using Tomcat, I dunno, but that's another rant).
Here's a bit of advice to people hiring: don't look for someone who can do the job; look for someone who can do the job having to leverage what they know and learn on their feet (and can demonstrate having done this effectively in the past). Why? Because the job will change, and those who can only do, but not think won't.
Oh sure, I've done the 120 hour weeks, usually because of a few of 24 to 32 hour sessions in there.
My advice: this is not something you want to do.
However, there are times when you know you aren't going to get your work done in the time allotted, no matter how hard you work. So, you have to work smarter, with better tools. Problem is, you don't have the tools. So, you get the insane idea to build them.
Let me rephrase this another way: You can't do what you have to in, say eight weeks, much less the two that you have, so, you figure out what you need to be able to do it in one week, and spend the other week building that. As crazy as this sounds sometimes it is a viable plan.
Sometimes the meta problem is easier to visualize, specify, and code than the problem itself.
Of course this requires a clear mind, focused on the task at hand, and more than a little courage: after all instead of 25% productivity for the time available, you expect to be at 0% real productivity for half of it and 200% for the other half. There ain't no guarantee that you're gonna be right. These kind of risks are best not mentioned to management weenies and those without the stomach for technical roller-coasters.
Others have mentioned that such hurculean efforts result in shitty code. Sure, you throw all the software engineering processes away, because they are just too heavyweight for that sort of thing. This is extreme programming at it's finest -- pipelined design, development, and test. Still, it will lack a certain, er, polish, and possibly robustness. But, you have an ace up your sleave.
See, you don't have to solve the meta problem of providing the tools to solve any real problem of a particular class on time -- you just have to solve it so it provides the tools for the particular problem you've got. Just make sure that whatever bugs there are don't manifest themselves on the particular data you have to deal with now.
Of course, anything that improves productivity is a good thing, right? Why not always take this approach?
Because solving meta problems instead of "getting one's job done" is not "getting one's job done" except in the kind of impossible deadline situations I mentioned. It's a pity, but that's probably not the business you're in -- while a particular C++ preprocessor to instrument memory allocation/deallocation and pointer dereferences might be a great product in it's own right, you just need to find the memory leaks in the code for which you have a customer.
Of course, with good project management, you won't find yourself in such situations, but such ideal circumstances rarely arise.
Slashdot Mirror
Sure, sure, I can pause and rewind live TV and have it record what I'm likely to like, and it gets rid of all those messy tapes. But, ya know, what? I can take that tape and shove it into any VCR in the house... or any other VCR, if mine break. While that's possible with Replay units, it's kinda klunky still.
Here's what I want: recordings in my inbox. Well, perhaps not emailed to me via the usual route, but dumped to some server in my home from some local device with a cable or satellite feed. But, I want the flexibility to deal with them as I would any other data in my home: stream them to whatever playback device I desire, make archival copies, etc.
I know, DRM prevents this. And it's true, but it does so in a far to heavyhanded way -- I want the days of fair use, and I'd accept mechanisms to constrain that use to being far, but not DRM as presently proposed or implemented.
As for a program guide subscription service: Unbundle it! Tell me how to tell the box what to record and let mo choose the service that will I can subscribe to to get that information in the necessary format to seamlessly integrate with the recorder. Yeah, if that means the recorder has to be sold for it's actually retail price, if I don't accept the manufacturer's subscription service, so be it.
With hard work, I managed to find another software development position, though somewhat different to what I had been doing: digital television graphics chip automated testing instead of telecom (which is really sick these days). The point is that tough times require flexibility -- automating testing systems had been a core responsibility of mine, in addition to development, and I can leverage those skills into an area of personal interest, without "real" professional experience.
In that regard, the 20 years professional experience helps, rather than hinders: there's lots about test automation that can be leveraged to different problem domains. Still, many would-be employers cared more for modern skill-matrix check-marks, than a proven ability to think ("No, I don't really do Java, but I have pulled some servlet code out of a nasty pickle, when necessary.") and didn't give my resume a second thought. Somehow, I got the impression that I didn't want to work for an organization with that attitude.
If I were to give advice to the "aging programmer", say 40+ like myself, it would be to stay as current as possible (at least conversationally with the latest fad, and preferrably having played with it), try to go the extra mile to be indispensible where you are (performance wise, not necessarily skill wise), and remain flexible in looking for new opportunities. Above all, try to not get depressed -- that fuels a nasty downward spiral.
Money is still tight, but for the past month or so, I had been ignoring the Salvation Army guy with the kettle outside the local Target store, and on Dec. 24, I slipped US$20 into the kettle.
O.K. So I always wanted to be able to afford to slip a $100 bill in there, but I figured this was a reasonable compromise between my family's welfare, and that of those less fortunate than us -- umemployment sends that message home pretty hard.
As for our plans, we are packing and planning a move. Sure, the $20 is a drop in a bucket, but I figure better that than nothing. Perhaps someday, I will be able to donate more, I had already donated a car to charity this year, before I lost the job.
Some will think me generous, others cheap. Frankly, I don't care -- I do not give for the sake of others' opinions. I do what I can, given my nature.
... in (a) reference to the fact that only partial bugs remain (milli being 1/1000th), and (b) that's where they all end.
One person whispers a short phrase into someone's ear who then passes it along in the same manner to another person, until the phrase gets transcribed by all people in the room, and the oft-hilarious result then disclosed.
I've often thought software development is like that.
Unless you're contracting directly with the customer, and note the requirements in his/her words, translating them to a technical equivalent (and, of course, translating back, and making sure you got the jist of what he/she wanted), you run the risk of these translation problems.
Often, such insulating layers are placed between well-meaning programmers and the customer to make sure they don't try to deliver more "work" than what the customer is willing to buy. This gets difficult because the programmer where the buck ends is expected to make the customer happy, but to spend the least amount of time possible on it, so that he/she can be assigned to the next project.
I've always thought that was a bad idea. Novice programmers' enthusiasm can be restrained by senior project leaders who might actually be the contact point with a customer -- they're called "systems analysts" for a reason -- the supposed ability to translate human-speak into technical requirements and estimate the work to be done.
In an ideal world, this estimate would be returned back to the customer via sales and a human-speak description of the work to marketting so they can get a feel what piece of it might be reusable on other projects and to feel the pulse of market desire.
More likely, much of this initial analysis is done by people not qualified to do it (sales and marketting types, though technically savvy people do exist in such roles), and critical customer requirements are either lost or not questioned.
I've been in situations where a customer's technical team rejected outright our technical proposals purely because of miscommunication across our respective management hierarchies. I've also been in situations where such miscommunication finally gave way to both technical groups getting together to convey an understanding of what's really wanted, usually after wasting much time and money. Often, in such meetings, one can almost feel the light bulbs finally turning on above the heads of those responsible for the confusion: "Oh! So when you said you wanted it ON a hard disk, you meant INSTALLED on the hard disk in the system, say, from a CDROM, and not DELIVERED that way!!" In all fairness I can see both ways being legitimate software delivery systems (the latter particularly if you're serving as hardware integrater too), but it is important to recognize the ambiguity and resolve it early.
What I've found works is a close technical liason to define the work to do, but, of course, no programmer delivers anything except through official channels, which are gated by the money stream.
To answer your question, if you don't mind a C++ focus, may I suggest that you read Andrei Alexandrescu's "Modern C++ Design", Addison-Wesley, Boston, Mass., 2001, ISBN 0-201-70431-5. Among other things, it offers a way of facilitationg the explicit coding of design pattern implementations.
Sounds like a great win to the VCR manufacturers OUTSIDE america (since from the article it says that it will be illegal to make vcrs without the devioce o' doom IN AMERICA). I mean, patriotism in America is pretty big, but will people buy handicapped devices just because they are made in usa? I doubt it. You'll buy the properly working vcr's from outside
I'd think that it would be illegal to import such VCRs because they would be circumvention devices. Thus, I can't see this chanelling American demand to foreigh suppliers, as you seam to imply. It would mean that there would be no demand for such crippled VCRs outside the U.S. So what? Most likely, the crippled VCRs would be foreign-made anyway. Just another variation on the basic product.
This is not the same as the issue of limiting export of American-developed hard cryptography: there, such limitiations were silly because foreigners are quite good at developing their own crypto, and would have no need for crippled American versions. That was an example of legislation which was ineffective in controlling access to crypto technology outside the U.S. The present case is an attempt to control access to technology within the U.S. - arguably easier to accomplish when it comes to hardware.
Besides, it is the only language AFAIK where "PERFORM INTERCOURSE VARYING GIRL FROM WIFE TO MISSTRESS" is legal (however, IIRC, one can't have a VARYING and say, "UNTIL TIRED" clause in the same statement). Oh well.
It does rot the brain, though. Kind of like Javascript -- a language so tied to a particular application that it's difficult to use it for general purpose programming. Of course, it can be argued that it was never intended for general purpose programming. "COmon Business Oriented Language"... get it?
I still chuckle at the time I was doing a short stint for a company that received some data from a client for an application we were developing for them... no one could decode it, until I realized it was probably a COBOL COMPUTATIONAL-3 encoding. Sure enough...
Well yes, but there are several problems with laws like this:
1. They suddenly make an assumed legal activity illegal. People have come to expect that they can time-shift broadcast TV with VCRs. In fact, their right to do this has been upheld in the Sony v. Betamax case. While this can change, it hardly serves what the public wants to do with the content it receives.
2. Because of history (see 1, above), there is something that seams fraudulent about suddenly depriving people of a capability they had. I doubt that this new "feature" will be widely advertised.
3. Criminal laws are enforced at public expense. If it is impractical to enforce the law (i.e. the technology can be easily circumvented), expect either increased taxation to fund the "war on time-shifting" or selective enforcement.
don't you own your house?, what about the broadcasted waves that go through your place?. can't someone make it ilegal to broadcast copy-controlled content through his/her house?.
Difficult. Yes, you own your home, subject to eminent domain, zoning laws, and HOA covenents. But, your elected representatives explicitly permit broadcast television. About the only thing you could fight are excessive radition levels (i.e. someone getting a broadcast license and putting up a tower right beside your home -- but that doesn't happen).
In the case of cable, since you permitted the installation in the first place, you'd have no case.
i don't live in the us, but if this gets passed, it probably will spread to third world countries such as mine who are always passing laws in order to get more money lent.
Dunno. The dynamics aren't the same as with, say, the drug trade. I'd expect that similar laws would get passed by pressure from local content owners for the same reasons as in the U.S., rather than because of pressure from the U.S. government.
Over the years we (myself, wife, two kids, a cat, and a ginuea pig) have accumulated the usual amount of "stuff". Facing a move, we're getting rid of stuff we don't really need: donating old books to the library and either discarding or giving away junk (and yes, that includes a lot of computer/electronic related junk, on my part). But that got me thinking: "Why have all this stuff in the first place?"
Of course, as a geek, I've always wanted to serve music and movies from a central server to client machines around the house. Recently, I've been able to accomplish this, but the real motivating factor lately has not been the "neetness" coefficient in doing this, but the pleasure in not having to have "media" cabinets in entertainment areas, with increasing amounts of media (CDs, DVDs, and legacy audio and video cassettes, and vinyl albums) that threaten to overflow the capacity of the cabinet -- in my younger and perhaps more foolish days I had a solid-oak and granite cabinet designed, with a modern look, to accomodate 240 CDs, 90 cassettes, and my B&O Beosystem 5500. Looks great, even 15 years later, but what happens when I get CD #241? At least now, it makes sense to archive the actual media, possibly refreshing the content to more dense media over time, serve the content from hidden servers, who's capacity can grow with technology, and generally upset the ??AAs because of the unscrupulous applications of the means to do this.
Homes appear to be designed to accomodate "stuff", more or less depending on how much material wealth one has. My take on this is that they should be designed to reduce the need for "stuff", in the first place. To be sure, proper networking to accomodate information and entertainment data is part of this (heck, even my bills arrive electronically, and I get an end-of-year CD from PayMyBills, instead of ever-increasing file storage), and a large part, and a lot can be achieved with a "data" headend and appropriate wiring in even a modest home, but it's just the start.
Clothing, kitchen, and garage storage has got to be among the most inefficient use of space there is. Why do we need wardrobe cabinets and dressers? Why not simply provide enough closet space in bedrooms? Or "bench"-style storage, kind of like Captain's beds, but all around the room walls, modular, and the right height to put things on, much like a dresser. Wouldn't take more space than a dresser, and, most importantly, it would mean that you don't need to own a dresser for each bedroom. Modularity in such units (rather like kitchen cabinets) would be most welcome. If you want to go all out, eliminate the bed foundation: build it into the room, needing only a mattress and box spring, with sufficient modularity to accomodate single, double, queen, and king. Unless you really want your bedroom to be a second living room, with a certain "style", a bit of a "cookie cutter" look, if it saves on the need for furniture, would be great -- you sleep there, after all. Personalization can take the form of wall hangings (posters, paintings, photographs, LCD or plasma displays, etc). The place for style and traditional furnishings, IMHO, is in the more public areas of the home: living, dining, and family spaces. Personally, I'd be happier with smaller, more functional, bedrooms, with the reclaimed space added to the other areas of the home.
On to kitchens.
Cabinets... can't have enough kitchen cabinets. Why? Because there's no standardization when it comes to kitchen utensils and plastic storage containers. Take a cutlery drawer: one usually has a plastic insert that holds forks, knives, table spoons, teaspoons, forks (regular and desert). All the odd-sized "infant/todler" stuff, garlic presses, tea infusers, chopsticks, hand can/bottle openers, etc. get dumped into the "miscelaneous" part of such an organizer and invariably overflows into the reset of the drawer. What a mess. While the basics are taken organized, the rest piles up. There should be a "standard" kitchen set, designed to be stored in a modular insert for a standard kitched drawer that accomodates 95% of the most common kitchen items. Oh sure, you'll always have the rarely (or less-rarely if you like to cook) used implement, but there is something wrong when a kitchen drawer insert's largest part is for miscellaneous stuff, and it's too small.
Plastic storage containers. The round ones really waste space, and the square/rectangular ones don't fill cabinets to a decent packing density. Cabinets, fridges, and plastic leftover storage containers should come in standard sizes (the first two probably do, but that doesn't help the latter). I'm thinking like 19" racks with 1-3/4" spacing per "U" -- except, call them "K"s, for kitchen: you'd have 10, 12, 16, 18 "K" cabinets in various widths (multiples of, say 4-1/4") to accomodate 1, 2, 3, 4, etc. "K" storage containers in multiples of the same standard width. Drawer inserts would conform to this standard too, so you can have the extra cutlery for 8 stashed in a cabinet, perhaps.
Kitchen cabinet shelves: make them slide out, dammit! And fit in the dishwasher (being dishwasher safe, of course). This is probably most important for pantry shelves, which accumulate bread, cookie, sugar, salt, pet food, and other debris, but, as we all know, the pantry overflows to an extra cabinet (at least it does for cat food in our home). Naturally, they should be adjustable-height. Modern kitchen cabinets come close, but, while removable, and adjustable, they are not designed for this to be done on a regular basis. Oh, and while we're finishing up in the kitchen, standardise the sizes of canned goods to match the pantry/cabinets.
Laundry Rooms. Every house needs one. My first two had just had the washer and dryer in a corner or closed off section of the basement, and the last one (built recently) actually had a separate small room. The latter works well, but gimme storage space for all the cleaners to keep there (not just detergents). Two storey homes really need a laundry chute -- bring it back. And, oh, a dumbweiter to take the folded laundry back up. As long as we're on the subject, why haven't we solved the problem of the bursting washing machine hose, huh? Yes, one should always turn off the main taps when not in use and not keep constant pressure on the hose (or rather the washers, which are what tend to give when you are 3000 miles from home), but who remembers to do that? (Well, I do, but my wife doesn't. /me ducks). Why the @#$%^$# don't washing machines have standard control signals for fail-safe water solenoid-controlled valves instead?
Living/Dining/Family rooms: here's where the style of the home/occupant should show and really be the only place where "furniture", in the classic, non-modular sense, should be needed.
Garage/storage: why ultrasonic bumper ranging devices aren't standard, with large LED distance readouts, or at least red/yellow/green "traffic" lights, I dunno. I guess people really do manage to park their monster vans with 1" to spare front and back, without difficulty.
Interior walls: repeat after me: should be movable. Within the limits of structural integrity, most interior walls, separating sleeping areas from each other, and from other living areas, should be removable. Yeah, this is asking a lot, espescially if it is to look O.K. without any ugly attachment points on the walls/floor, ceiling. But it would be real nice to change a 2 master, 3 bedroom house, into a 1 master, 4 bedroom house, when the second kid comes along.
Of course, these are just my thoughts, off the top of my head (or, depending on your opinion, pulled out of my a**), but I definately think there is room for improvement and some degree of modularization/standardization in the house building industry.
Certainly, there are a variaty of ways to distribute an application, when you start to have real compute power at the human end of things, but they're all variations on a distributed processing theme, conveniently placing a "tier" at an architectural point with clean, simple, and few interactions with components at another tier. Hence, three-tier and n-tier applications: they're just particular distributed "sweet spots" particularly appropriate for certain large classes of applications.
In the old days, if we even considered such distributed systems (requiring a PC on a desk, instead of just a terminal), we coded all the protocols, marshelling schemes, and so forth ourselves -- it was an in-house thing. So, yeah, all such distributed applications look the same, from that perspective, the way that all large C or C++ applications "look the same", if well-designed.
But, as particular distributed mechanisms meet large "sweet spots", such as a web browser/server split, they're pushed as the definitive "answer" to man-machine interaction.
And, just as quickly, or shortly thereafter, the shorcomings of a particular popular distributed architecture split become apparent, and the next "model" is pushed as the definitive "answer". The fact that it is tuned to a different class of problems is generally lost on those flogging it, and those buying it. The rest of us just kind of look at it and say, "yeah, so?" -- after filtering through the buzzword muck.
Now it is true, that, as client-server models (and all of these are just that, really) mature and are pushed into use, they are strained to the limits of their scalability, and two-tier architectures give way to three-tier architectures, and so on. So the new tunings offered by the "latest" architectural split does serve to solve new problems, but that in no way invalidates the fact that the "old" architectures did a splendid job of serving to solve the "old" problems.
The frustrating thing, from the perspective of someone like me, having worked with all sorts of distributed systems for close to 20 years, is the notion that one such architecture is sufficiently different from another that the "old skills" are now obsolete: client-server techniques do not transfer to three-tier architectures do not transfer to, what's the buzzword?, oh, yeah, "Web Services".
While the interfaces are new, and the implementations of the various components need to be picked up, a seasoned architect will look at them an say, "yup, that should scale the way we need". However, there is this notion that this can not happen quickly, and new "experts" need to be hired to replace the "old" experts.
Funny, most places don't get rid of their "if statement" C++ programmers when they need "while" statement-, or golly gee, "function call"-programmers. Understanding of standards particular to a given architectural model may be important, but it's such a small part of rolling out a working system, that any competent software engineer can deal with them.
Don't make the mistake a former employer of mine made: contracting out some servlet code to "Java experts"... that had no clue about threading issues because, while they "learned Java", they knew nothing about multitasking issues. Hint: those that understand the latter generally adapt to a different language faster than those that know a single language adapt to other than basic computer concepts. And so it is with buzzwords designed to obscure the obvious.
Publishing for paper and on-line versions is getting increasingly common. Furthermore, if you are producing paper versions in a big way (i.e. using the services of a printing company), you probably need to produce output in an acceptible interchange format, with split color layers, etc. (Oh, FrameBuilder did that SOOO well!)
The point is noted: in a free market you always have to watch your back for the competition, lest they sweep by you. However, there's a bit of a difference between incumbent word processors and web browsers (Microsoft vs. Netscape).
The word processor requires a significant investment to learn, if you're going to use it to produce documents with any structure or complexity (cross-references, indexes, tables, consistent style, etc.) There is no such learning curve for a basic use of a Web browser. So, abandoning one for another is a lot less painless than migrating from Word, to, say, FrameBuilder (which, IMHO, is a programmer's and publisher's dream to use).
Thus, once an investment is made in something complex, particularly when its utility is enhanced by network effects, it's difficult to change.
Now, I hear you all screaming, "WordPerfect!". Truthfully, Word offered more elaborate formatting control, to make the transition from a simple "text formatter" to a "word processor" worthwhile -- providing greater functionality (and locking in a commitment to greater complexity). Yes, WordPerfect caught up, but it was a question of too little too late, espescially with Microsoft's intergration of their office suite components.
Now, there is still hope: an XML-based standard document format can offer something that is difficult at best to do in Word: separating style and output from content: a single document could end up rendered in PDF, HTML, plain text, or conceivably, Word formats (though RTF is more likely than Word, and importable into same, IIRC).
Besides, quad-shield is not that much more than double shielded, and as long as you're hauling cable, might as well.
Ever wire a house for voice, video, data? Well, there's a rather standard way of doing it and it involves two four pair cables (Cat5e, generally, though in the "old" days, if you were penny wise and pound foolish, you'd run one Cat3 and one Cat5, or worse, one quad "Jake" and one Cat3), and two RF cables (RG-6/U, preferably quad-shielded).
One of the quad-pair is used for data, the other for phone (some of the more complex phone systems actually need all 4 pairs); one of the RF cables is used for distribution from the headend, and the other for modulated distribution back to the headend, to distribute your DVD throughout the house.
It's supposed to be the most cost-effective way of doing things: cheaper to RF-modulate an analog signal than do real-time MPEG2 encoding to stream over IP, right? Same for the phone stuff, though, as the original query hints, not out of the realm of afordability to do it over IP. And all that cable! Do you know how thick a bundle of 2xCat5e and 2xRG6/U is? About 3/4-7/8 inch. It's a real pain to retrofit into an existing house. Been there, done that. Wireless data networks start to look real attractive.
Now, you can get products like SpeedWrap that add an extra jacket (and some even include Fibre), which makes deployment a bit easier, but the cable costs about double what individual cables do (still, if you're paying for installation, it can be worth it).
Yeah, it would be real nice to do it all over IP, and thus, one 100BT or GigE network connection.
I've often thought of a "per-room" interface box, with network in, and telco, intercom, digital audio, and video outputs and possibly digital audio and video inputs. The idea is to interface to legacy equipment (like standard handsets, intercom speakers, stereos, TV's, etc), with one little wire snaking back to the headend. Computers, of course, connect directly to the network. You might want to splurge and have several nets: entertainment, data, and DMZ data. Such things would be a real hacker's dream to design, build, and deploy.
The kicker, of course, is cost. A phone and a bit of wire is way cheaper than this kind of tech, which requres, effectively, a fairly powerful computer in each room to be networked. Gigabit ethernet switches don't come cheap. Start running MPEG2 video around your home lan and the ??AAs will be all over you for "infringement". Still, Moore's law being what it is, in about ten years, such things could be made as cheap as doughnuts.
Yeah, this went off-topic, and didn't provide any tech solutions for IP-intercoms, but it does warrant examing the bigger issue of putting all of a home's digital and digitizable traffic on a LAN.
To do this, you only need four interfaces per node (actually, you need two transmit and two receive, so could get away with two, but let's stick to four so we don't have to hack network layer code).
Assuming you have 2^n nodes, you number them from 0 to 2^n-1. Node n is configured to transmit to nodes 2n mod 2^n and (2n+1) mod 2^n. By extention, it receives from nodes n / 2 and n / 2 + 2^(n-1).
This lets you get a message from one node to another in at most n hops with 2^n nodes and four (or two) nics per node.
The point is noted, and I can only write from my own experience with picking up new things "on the fly": my history has always (though past performance is no guarantee of future results) been one of going from novice to expert, and exceeding the skills of the resident experts, in short order.
Certainly a rich and broad inventory of classes with which to attack a problem takes time to learn. But again, I have often found those who know the inventory often can't judge the applicability of a particular architectural choice for lack of an understanding of implementation details that "leak", i.e. performance, memory footprint, etc. Generic skills come in handy here.
If I were to seek a position where Java was the primary implementation language, I would consider an intermediate development position, and certainly not an architectural role, at least not right away. But, what's upsetting is someone not realizing that over a decade of OO and expert C++ work, along with a demonstrated track record of adapting to new technologies, APIs, etc. isn't even considered superior to utter novice level with a new or different technology. The vast majority of the skills repertoire does transfer.
Oh yeah. Definately.
I'm one of the cranky, grizzled, old farts (well, 41, which, in this biz, is old). The early serious work I did involved Z80 assembler for X.25 PADS, switches, and mobile radio modems. Even code a FEC to combat Raleigh fading for a radio modem in a police car? We hacked practically to the bare metal 'cause that was the only way to get acceptable performance. We were few and far between, compared to the Cobol weenies that took "Business Programming" in school.
Of course, over the years, one moves from straight assembler, to C, to C++, and instead of rolling one's own kernels and schedulers, starts to use offerings like pSOS, and MQX, for real-time embedded apps, and Linux and FreeBSD for time-constrained work. And, one leverages language, and library, abstractions because they make your development life easier and more productive.
Then, something doesn't work. And, guess what? Us "old farts", who either understand the underlying implementations, or can make an educated guess about them, are often the only ones who can find and fix the problem. This skill often extends to areas where the abstractions are foreign: I once singlehandedly repaired a bunch of Java servlet and RMI code developed by an outsourced "Java expert" team, despite being quite the Java newbie myself.
The problem was simple enough: it was a thread-safety issue within the servlet engine, and "smelled" that way, from the looks of how it was failing. Damned, but I know all about those kinds of dangers and instinctively code defensively when it comes to multi-threaded code. The actual task of picking up enough Java to understand the intent of the code and the APIs being used, was no big deal.
I take that kind of skill, to drill down through the abstraction, and find and fix the problem, for granted. I joke, "That's why they pay me the big bucks!". I have found this skill lacking in many new graduates and people entering the field, having had abstractions and the language du jour rammed into their heads instead of basic computer principles: perhaps one in ten that I interviewed can sort their way out of a paper bag. That saddens me.
Yet, despite these shortcomings, it appears to be specific abstraction knowledge that's in demand, and not an inherent understanding of how the systems work their magic. To use an analogy, yes you need a chauffeur to drive you from A to B, but you also need a mechanic when the car breaks -- HR people are hiring chauffeurs on the assumption that cars never break or are abused.
If you need people who can adapt to whatever the abstraction of the month is, and drill down and understand the mechanics of the underlying implementations, call me. I'm looking for work.
O.K. I think I get the point you are trying to make, though XML and .NET are every bit as much technologies as Java and SQL, just new and thus "sexy", and prone to buzzword mining in resumes.
Where I criticize something as a "buzzword" is when an inappropriate weight is given to it as a skill, when compared to the general skill really desired: OO in the case of Java, query languages in the case of SQL, and structured data in the case of XML -- there are other examples of these skills and they should carry over: C++ experience should be a good fill for Java, evidence of handling structured data for XML, and experience with heterogenous systems interworking for both XML and .NET. That, and a proven history of adapting to a different flavour of the "same old thing" in record time will often be better than someone with recent Java and SQL Server experience as the only OO/Database expertise they have.
You are right about Smalltalk being single inheritance, I think, but, IIRC, it has a rich dynamic type system that C++ and Java can only dream of. As for multiple inheritance, I suppose multiple interfaces can work as a proxy, but then you have the whole member function virtualization overhead for them no? C++ is superior here in that you can have implementation composition without that extra indirection. Whether that matters in practice, is, of course, debatable: there is a whole school of thought that anything that can be done at compile time should, as a matter of optimization, but, OTOH, this stiffles dynamic run-time extentions.
Point noted re. SQL, but it's just a query language. Anyone with database theory should be able to pick it up in no time. More to the point, anyone who's used a more typical programming language should have no problem with something as simple as this, syntactically (though, it is also baroque in the same way that COBOL is).
As for Java, sheesh! What matters should be OO methodology and an understanding of n-tier architectures (which is but a physical manifestation of the former). Java is an implementation detail with certain nice cross-platform attributes (like client-side validation off-loading, etc.)
Perhaps I'm a bit of a crank about this, but having been in the position of implementing code to desirable "common", if not standard, APIs in an embedded environment from scratch, specific API knowledge does not strike me as it should be a major differntiator -- picking up a new API and language is trivial by comparison.
Of course, if Java is your first OO language, and you're learning the principles and practices of OO design, development in a heterogenous environment, good Java skill matters, but it's not really the Java you're learning, it's the nature of programming in that environment in general.
So, I'll still rank Java in the buzzword camp. The language matters far less than the overall architecture and really just represents a means to an end.
Could the same argument be made about C++, or other OO languages, like Smalltalk? Perhaps, but, unlike Java, they are richer in terms of the native OO concepts they support: multiple inheritance for one. Java scales back on a lot of these things (simply parsing C++ is, admitedly, a bitch), and adds more practical facilities (garbage collection and native multithreading) useful in a particular set of applications.
As for XML, and .NET, so what? Yet another interchange and serialization format, and marshalleling scheme. Sure, there's a whole bunch of support code around the technologies, but it's still just a different way of doing the same old thing. RPC/XDR was the big thing in the Unix world way before XML, and more efficient too.
I dunno, SQL, Java, and XML just give me an, er, COBOLish feeling: programming for non-programmers with a business app bias. I suppose we can afford the cycles to be inefficient for the sake of rapid deployment and easy inter-subsystem debugging, but the argument stands that if you could hack the "older, less friendly stuff", this new tech is not a big deal to pick up. Focusing too much on the most recent specific implementation technology of rather old principles does strike me as buzzword mining.
It is possible to know what something is used for without having to know exactly how to use it for that.
For example, I can make a solid reccomendation dropping Tomcat in place of Alaire's JRUN as a Java servlet engine, without knowing how to configure Tomcat -- that comes quick enough. Whether this is a good idea depends on an evaluation of Tomcat's stability and speed, whether any quirks of JRUN are being exploited, and so on. None of that really requires "three years experience" with Tomcat.
Now it's true that experience with the tool in question helps answer those kind of questions, but it is not the only way to get those answers with an acceptable degree of confidence.
Indeed, remaining focused on the tools with which you have expert knowledge often leaves you narrowminded when it comes to "out of the box" thinking to deal with new problems.
For example, we had a requirement, on a distributed internet test platform, for an administrative interface. As usual, implementing this kept getting put off and put off until it really became a critical path issue, which no one considered. So, we had the proverbial "zero time" to implement an admin interface, secure in the public internet. Bad planning? Bad management? Perhaps, but shit happens, and what separates the men from the boys is dealing with it.
Without knowing much about Apache or Linuxconf configuration or extention, it nevertheless was obvious that using Apache to proxy an SSL session to linuxconf's web-based interface would get the job done, with little "real work" providing linuxconf backends for our unique copnfigurable components. It may not have been the most elegant way to get the job done, but it worked, proved secure, met the requirements, and was done in time.
Now, do you think any of the "Apache" or "Web" experts knew anything about this? Nope. They had no clue where to start. I knew nothing about the specifics but was confident that these components could be glued togehter via configuration magic, and perhaps a bit of custom code, and a google search confirmed these suspiscions.
You could argue that webmin might have been a better choice, and without panic, a better analysis could have been done. But, so often, the ability to work with less than ideal specs and data is what keeps a project on track.
So, hire me. See sig. :-)
1. Do whatever YOU like, but do it well.
Some flexibility is necessary. I'm not crazy about Java, or scripting languages, for example. Of course, I come from an embedded background where you squeeze every last drop of performance out of your resources. Not everything has to be blindingly fast, and there is something to be said for rapid deployment. As much of a development geek that I am, I have found pleasure in streamlining build environments, generating test infrastructures, and producing customizable installation media. Even "mundane" tasks can be made superb with the right attitude.
2. Only work for employers that you want to get up in the mornings for.
Aye, though I'd augment that by saying, "Only do things that you like getting up in the morning for." -- the employer might be a bit of an ass, but the job can still be fun.
3. Dedicate at least 10% of your "work" time to professional development, even if you have to pay for it. Go stale = out of job
That's been my mistake. I never really got into the whole Java, J2EE, enterprise "thing", dealing with it when necessary (and damn well, at that). Also, it can be difficult to find that 10% when work time ranges from 60 to 120 hours a week to correct mistakes made by others -- the tragic flaw of having exceptional troublshooting skills.
There's a tendency to not "train" after having seen a lot of different, but similar, systems, because a good S/W engineer will pick up the required skills as necessary without wasting time on traning that may or may not prove useful. However, future employers like to see "training".
In an attempt to correct this oversight on my part, I have been spending some of my free time with "buzzword" technologies like SQL, XML, Javascript, and Java -- though the tendency does remain to think, "I'll pick this up when it's the right tool for the job and not sooner."
The difficult is that many employers will not believe that you can actually do this, even with a history of pulling off "miracles". Sell yourself too hard and you come off as arrogant.
4. If you're not having fun, leave. Life is too short to put up with crap.
Alas, one has to eat, and leaving is not always practical. But, the sentiment is noted.
5. Don't choose the boring staid job unless you want to retire. Be different. Work for Microsoft*.
Indeed. The best time of my life was working for my last employer, and optical router startup. Sadly, I got caught on the wrong side of a 20% cut to make VC capital last. Still, smartest bunch of people I worked with.
OTOH, after a while, one starts to think, "Ya know, why not take all one's savings, buy a cheap house in the country outright, and 'retire' to give the people at the local Rat Shack blank stares (or, if they're clueful, a surprise of knowledge).
If you're after buzzword compliance (j2ee, .NET, etc), read the other 500 posts. As you already know, they mean nothing in 5-10 years. My tips will last a lifetime.
Yeah, but the short term is a bitch.
Yes, that would be the democratic thing to do: one person, one vote. Period.
However, areas with high population densities would swamp the will of areas with lower population densities to the point that the midwest would probably not count at all. In that case, why bother being part of the Union?
Preservation of the Union of United States is one reason why representation is not purely democractic, and the President requires a wide degree of diverse support, even if the quirks of the Electoral College system mean that he or she does not get a majority of the votes cast. These same quirks tend to favour two party systems and make it extremely difficult for third parties to get a foothold. From a stability standpoint, that probably isn't a bad idea (even as I am a staunch third party libertarian supporter).
Ideally, these quirks would not matter, since the President heads the administrative arm of government, and not the legislative one, comprised of the Congress and Senate. However, the past 100 years have seen an increase in executive powers that likely exceed a healthy limit for a purely administrative head of government.
Of course, with close to 20 years work experience under my belt and graduate degrees in Computer Science, you'd think I should be able to adapt to anything and pick it up in a hurry: I know enough about customs and trends in programming language syntax design and the way distributed systems are architected, as well as issues related to inter-process and inter-machine communication.
Recently, I found myself looking for new work.
It's a tough market, but I'm adaptable, with a proven track record, and willing to take on n-tier ecommerce applications if I have to, despite really liking things like silent set top box designs that suck and decode MPEG2 video from local or remote servers. So, I start looking.
Java, Java, IIS (ugh!), Apache (well, O.K.), PHP (yea, looked at it), mySQL. No big deal, right? C++ and OO skills in general port to Java (it is a simpler language after all), and hey, once you get the code classes and a bit of Swing or AWT, you're rolling. A week, tops. mySQL requires a quick study of SQL syntax and the particular ideocyncracies of that implementation. Yeah, I've configured Apache a couple of times and even set up an HTTPS to HTTP proxy within it for a linuxconf HTTP administrative backend. Kinda cool.
"But, you don't have any real Java experience," I start to hear, more and more frequently. Well, no, I don't really do Java -- I use the best tool for the job, and if Java fits, I use it. It just rarely was appropriate for the domain I worked in (real-time embedded telecom and data acquisistion). But hey, need something client-side in a browser, and yeah, Java is the ticket (unless it's so trivial that Javascript will do -- where's my DOM manual, again?). So? I didn't do Python either, but that didn't stop me from extending Red Hat's Anaconda, did it? And what about the time I had to handle a bunch of regexp matching -- perl was just the ticket. Someone embedded tcl in something we once inherited, so, time to pick up tcl.
Of course, no one believes that anyone can be so versatile, except other people equally versatile. Almost certainly, this excludes HR people. Otherwise, they wouldn't be in HR, would they? They'd be along-side designing, and developing the future.
No, I don't really do Java -- I just pick up the pieces when the outsourced "experts" forget to synchronize appropriate members of the objects they have living inside a multi-theaded servlet engine (why we paid big bucks for Alaire's Jrun instead of using Tomcat, I dunno, but that's another rant).
Here's a bit of advice to people hiring: don't look for someone who can do the job; look for someone who can do the job having to leverage what they know and learn on their feet (and can demonstrate having done this effectively in the past). Why? Because the job will change, and those who can only do, but not think won't.
My advice: this is not something you want to do.
However, there are times when you know you aren't going to get your work done in the time allotted, no matter how hard you work. So, you have to work smarter, with better tools. Problem is, you don't have the tools. So, you get the insane idea to build them.
Let me rephrase this another way: You can't do what you have to in, say eight weeks, much less the two that you have, so, you figure out what you need to be able to do it in one week, and spend the other week building that. As crazy as this sounds sometimes it is a viable plan.
Sometimes the meta problem is easier to visualize, specify, and code than the problem itself.
Of course this requires a clear mind, focused on the task at hand, and more than a little courage: after all instead of 25% productivity for the time available, you expect to be at 0% real productivity for half of it and 200% for the other half. There ain't no guarantee that you're gonna be right. These kind of risks are best not mentioned to management weenies and those without the stomach for technical roller-coasters.
Others have mentioned that such hurculean efforts result in shitty code. Sure, you throw all the software engineering processes away, because they are just too heavyweight for that sort of thing. This is extreme programming at it's finest -- pipelined design, development, and test. Still, it will lack a certain, er, polish, and possibly robustness. But, you have an ace up your sleave.
See, you don't have to solve the meta problem of providing the tools to solve any real problem of a particular class on time -- you just have to solve it so it provides the tools for the particular problem you've got. Just make sure that whatever bugs there are don't manifest themselves on the particular data you have to deal with now.
Of course, anything that improves productivity is a good thing, right? Why not always take this approach?
Because solving meta problems instead of "getting one's job done" is not "getting one's job done" except in the kind of impossible deadline situations I mentioned. It's a pity, but that's probably not the business you're in -- while a particular C++ preprocessor to instrument memory allocation/deallocation and pointer dereferences might be a great product in it's own right, you just need to find the memory leaks in the code for which you have a customer.
Of course, with good project management, you won't find yourself in such situations, but such ideal circumstances rarely arise.