Firefox 10, Chrome 20 - I Remember When Versions Mattered

Call me old and out of date. Go ahead.  I'll wait..... ... .. ..... .... I fell asleep, sorry.  Where was I? Oh yeah, I was about to embark on yet another rant about the sad state of software development and business overlords.  You're not going to believe me, but I haven't consumed any alcohol or caffeine prior to writing this lengthy torture of the senses.  It's true.  I'm actually about to fall asleep following a long day and a rigorous workout, which was long overdue.

Here it is in a nutshell...

In the 1990's, software products were made by developers.  Those days are gone.

In 2012, software products are written by developers, chained to their cubicles by leather thong-wearing MBA "marketing" and "project" management freaks with gold-plated gas masks on.  They are marched into conference room meetings to discuss project plans, schedules, resource allocations and who keeps fucking up the toilet in the men's restroom.

It's all about shareholder value now.  I'll repeat that...

IT'S ALL ABOUT SHAREHOLDER VALUE NOW.

The misty-eyed days of developers passing the bong around, followed by the Dorito's, and the warm cans of Bud Lite, sharing ideas of revolutionary paradigm shifting, are gone.  Splayed out like a Mexican drug execution scene, over an assorted mismatched array of bean bag chairs, and futons, orange crate coffee tables, with Led Zeppelin or Buckethead playing in the background.  Discussing ideas for the next cool software project or feature update.  Losing a bet over the lyrics to that last song and having to drink the bong water.  GONE.  Actually meeting with users (we didn't call them customers back then, that came later, after the suits invaded) to discuss what they like and don't like.  Then actually, get this, you're going to call bullshit here:  went back and incorporated the user's ideas into the software product.  Amazing!

Gone.

Developer's today talk mostly about the following key points:

• How to leverage "social media" and "social networks"
• How to infuse HTML5 or J-Query into their app
• How to build a brand and sell it to the first bidder
• How to get t-shirts printed for their weekly bungee jumping team meet-up
• Putting up a new web form to get customer feedback
• Building in telemetry to collect user statistical data
• Taking bets on the IPO share price, for, you know, whenever you IPO

Sure, there are some clever kids smacking the monkey keys, and a lot of them can do amazing things with the latest toolz.  Notice that hep "z" ending there?  Ha!  I'm still a hep dude.  Oh yeah.  They can do truly amazing things.  But unless they have a messiah leading them through the valley of the shadow of venture capital, they won't fear evil, but evil will own them soon enough.  A messiah like Zuck, or Mason, or Williams, Brin or Paige, offers vision over stock shares.  The longer they can hold those beasts at bay the more time they have to cultivate vision, ideas and build great things.  But eventually, the boardmembers take over and that's that.

The problem is that developers alone can only do so much before they hit the point where they need to sell something in order to support their dreams.  Eventually, they'll need money. Money requires indebtedness, which requires becoming someone's bitch on a leash.  The leash holders want some ROI (that's RETURN ON INVESTMENT, for you kids that skipped business class to huff Redi-Whip cans behind the gym).  The lenders get money from their investors, who in turn have only so much patience before they see a return on their dollars.

Your caffeine-pumped, sugar-infused, emotionally-charged verbal carpet-bombing about "totally radical" and "gnarly" new features and the latest ball-crushing, brain-exploding technological uber-wonderness is about as effective against the multi-syllabic brain of a standard issue, model B, type I, mark IV, suit-encased, managerial labor unit, as Charlie Brown's school teacher.  All they hear is "wah wah wah wah J-Query, blah blah Dot Net, blah blah, XML something, blah blah AWESOME!".  They're more likely to have remembered the exact count of how many times MC Coder wiped Rock Star dribble from his mouth than the names of any of that techno-babble.

This is not how it used to be, kids.

There was a time, way back before Facebook, even Google, existed, when software was conceived, built, tested and supported by (get this, you're so NOT going to believe this...):  developers!

No. I'm not kidding.  For realz!  (see that "z" again?  ha ha!)  Don't believe me?  Check out the historical photos below.  On the left you see imagination at work.  Actually, they didn't think of it as work, even though they busted ass for insane hours with few breaks.  On the right you see the seats, to be filled with whoever occupies the board's latest organization chart for discussing the budgets, cash flow, valuations, ROI, SWOT reports, and most likely: a never-ending "renewed focus" on cost reductions.

They were good times indeed.  At least, what I can remember of them.  It's a bit cloudy, you see.

But as for the early on reference to "Firefox 10", that was a sidebar thought actually.  The reason behind that was that in those bong-slinging dayz (did you catch it this time?  good.  you're coming along nicely!) they actually used a fairly consistent rationale for applying version numbering.  Granted, there were variations and deviations, but compared to today, it was 100x more consistent, even across UNIX forks, Windows 3.x and NT, and Mac OS.  A "major" version meant a radical, significant, kicked square in the crotch with ice-climbing boots on, change.  Earth shattering.  Paradigm shifting (back when that meant something as well).  An "Oh shit!" moment for most customers (smiling as they said it).

A "point release" or "minor release" was for tweaks, upgrades, adjustments, etc.  Or as to put it in terms of one of my professors...

Major = Revolutionary

Minor = Evolutionary

I'm sorry, but Firefox 5, 6, 7, 8, 9, 10 are really minor releases.  They didn't completely overhaul the entire product with each of these, so why did they do this?  Marketing.  Pure and simple marketing.  When market share is stagnating or falling, you have to pump up interest, and that demands turning on the Hype machine.  The Hype machine as a huge funnel on the top that you feed copious amounts of bullshit into and it grinds it into marketing material.  Brochures, Memos, Pamphlets, Web Sites, DVD's, fold-up kiosks, TV ads, and tons and tons and tons of meme terminology to verbally inject into the brains of anyone withing talking distance.

I have to tip my hat to Google for at least not only playing the version numbers down, but almost ignoring them entirely.  You don't ever see a blurb about the "new version 16!" for Chrome.  Never.  You have to dig for it yourself.  Sometimes (especially if you're on the dev channel like I am) you aren't even sure what version you're using until you stop and check.

The Future

The future is always the same.  I forget who said that, but it was someone famous, I'm pretty sure.  Facebook is about to do their IPO.  They will slowly succumb to the boiling frog syndrome, whether they like it or not.  The heat will start out low, and gradually increase, over months or a year, but not too much more than three years, you won't recognize Facebook as it is known today.  It will become another corporate cube farm with the expected food court, exercise facility, and Zuck will gain 40 lbs and start balding. Trust me, I've seen it before.  As it starts to stagnate, users will be watching for the "next big thing" and flee like rats as soon as something shiny and blinking comes along.  That may take a few years, but it will happen.

And that, kids, is why the future of software development is going to suck.

Cheers!

Read More

Regional Autonomy and Applications in the Enterprise

Unlike most of my rants and posts, I'm not going be able to propose a solution here.  This one has no solution.  It is simply a situation that exists in the VAST, and I mean VAAAAAAAAASSSSSST majority of "enterprise" business environments.  Read that as "big companies", "large organizations", or whatever you wish, but you get the point.

This is really an example of the Human Condition.  That is, the desire to achieve some semblance of "order" while also achieving some semblance of "freedom".  Be it Federal versus State, Public versus Private, Teacher versus Student, Owned versus Licensed, Urban versus Rural, or what have you.  It's a quandary that will never be resolved because it exemplifies Yin and Yang, which like Hot and Cold, or Black and White, will always coexist in the Universe.  We must always strive to adapt to the existence of such dualities as being necessary counterparts, rather than try to bend them to our Will.  The problem is: as Humans, we cannot avoid wanting to bend them to our Will, and THIS is the dilemma.

Allow me to digress...

You have a central IT operation that strives to maintain control over a consistent and predictable environment.  That is a noble goal.  It makes sense.  After all, a business cannot quantify it's operational successes and deficiencies without being able accurately quantify, and quantification depends entirely upon predictable elements upon which we can model situations and outcomes, hence the term "known quantity".  Without quantification, we cannot qualify a strategy either. Qualification requires quantification in order to provide a meaningful rationale.  It simply is not practical to forecast how long it will take, nor how costly it will be, to climb to the next level if you cannot determine what kind of ladder is being used.

The IT operation, typically being a cost center within a typical Western style corporate structure, is an inherent part of the operational fabric of a business.  In order to bolster the "bottom line" and keep costs down, they must commoditize many services and products internally.  The term "commoditize" comes from "commodity".  While defined as having a characteristic of being interchangeable (see Merriam-Websters definition), "commodity" doesn't specifically include a reference to quantity or uniformity, however, it can be argued that in order to be effectively "interchangeable" implies an aspect of uniformity and consistency.  The spirit of the use of this term is in the realm of achieving a standard unit which is easily replaced, and therefore easily mass produced by virtue of consistency and functional attributes or behavior.

To commoditize IT services and products is to attain a standard form, which is easily measured, and who's application is easily predicted in terms of it's impact on the business. Commoditization usually finds its way to the production environment in the form of "trouble ticket" systems, call centers, standard configurations of devices, SLA's, SOP's, standard software products (aka "Software Catalogs"), rate structures, tiered service plans, and so on.  How they are funded varies, but the goal is usually the same: Attain a predictable and stable environment.

The business operations outside of IT have their own agenda, often due to not being a cost center, but rather, a profit center.  While officially part of the same team, answering to the same overlords, profit center players often set different goals, use different metrics, and march to a different drum than the cost center folks do.  One aspect that differs most is that while the IT operation seeks to gain stability and consistency, the profit center is all about flexibility, and speed.  They are not just focused on these two aspects, they are quite often entirely consumed by them.

This is where the two worlds, IT and profit-center operations, diverge and often clash.  One wants to roam freely and hunt down whatever they want to kill.  The other wants to build a fence and establish order.

They may clash subtly, with only a smoldering collection of personality conflicts, or may experience emotional outbursts and clashes of great magnitude.  The range varies by personalities involved, pressures on each side to meet objectives, and the nature of the business in which they operate.  Indeed, the stories of these cultural divides in many companies is often legendary.  These are often what drive the most basic yet core cultural aspects of any company.  This is often because of personalities, allegiances, politics and strategy, typically ahead of stated business goals.

Not tangible enough for you? ...

The Marketing department at Contoso (sorry, a MCITP exam reference), has encouraged several of their younger and motivated staff to develop tools to allow them to meet crucial short-term goals, as well as help strategize for the longer term goals.  They cultivate a crop of applications and content over time that helps them shape their operational processes.  It might include Microsoft Access, Excel, Adobe Photoshop, Adobe Illustrator or even Creative Suite bundles, maybe QuickBooks, and an entire army of lesser-known specialty products, that all fit like a puzzle for their needs.  The arsenal can grow staggeringly huge over time.

Life is good for the Marketing folks.

Then comes the IT department and their desire to upgrade the operating system and standard software bundle on all the company's computers to gain some improvements in manageability or capability.  Maybe they are looking to migrate from Windows XP and Office 2003 to Windows 7 and Office 2010, it doesn't matter, you get the idea.

The developers in the Marketing group announce their opposition to the upgrade because it will "break" many of their custom tools and processes.  This is said to be due to having built a large number of Access database applications with integral VBA, forms and reports.  The developers insist that tests have shown poor results when trying to upgrade them directly into Access 2010.

The time and effort required to upgrade and test them to work with the proposed upgrade is determined to be cost prohibitive by the Marketing department, so they insist IT, or corporate administration, pay for it.  The IT department objects to paying for it because the tools were developed outside of approved processes and by unqualified personnel.  Corporate Administration shakes their head at what they perceive to be a power play by both parties that feels like two children fighting over a ball.

The IT department argues that if they are going to pay for the upgrade, then they earn the right to take over the stewardship and maintenance of the application to avoid future mishaps.  They insist that they are better trained and equipped to develop software than self-taught college kids, and that they can apply process maturity (read: CMMI, SDLC) to improve quality and reliability.  They accede to the claims that this will slow down the process for implementing feature changes, but IT insists it's for a good reason.

The Marketing department argues against losing control, and to the slow turnaround by the IT processes.  They also worry about relative priorities, as a requested change might be priority #1 for Marketing, but #50 for IT in the aggregate queue.  Marketing panics over the thought of having to wait for the IT developers to gather requirements, analyze them, apply the usual project management sloth framework, and dedicate 0.25 man-hours to three developers, enter the request in a queue, and wait for notification that it's ready to test.  Then deal with the methodical, and tedious, project management process to get from Dev to Test to Production.

Marketing has depended upon their own predictability factor: having their own developers on a short leash with direct control over their own priorities.

Neither side budges until either (A) an incentive is introduced, or (B) a threat is introduced, which tips the balance to one side or the other.  Only then is there any significant movement towards resolution.  But when it's regressed to this emotional level, the eventual "resolution" is not what anyone had hoped for.

If the balance tips in favor of Marketing, the IT folks see it as a vote against their primary objective: control. If it tips in favor of IT, the Marketing folks see it as a vote against their importance and value within the overall priorities of the company.  The losing side, whichever it happens to be, sinks into a mental state of "good enough" and "why try harder" since they now see themselves as having been diminished.

And so the the battle begins.

Any of this sound familiar?  I have personally watched this scenario play out, almost exactly as described, dozens of times.  I still see it all the time.  It will never end.

Read More

Job Tip 47: High Turnover Warning

There's lots of advice about seeking a new job and what to look for, how to look for it, when to look for it, and where.  You hear a lot about how to investigate what an employer does (line of business), what their current situation is (market performance) and future prospects (news reports).  That's all great advice to follow, but there's more.  You also need to know the bad side.  Just like when you visit a new city, most people will eventually want to know where the "bad parts" of town are, so they can avoid them (or if you're a thrillseeker: get there faster).

Maybe you're one of those people that likes to keep one eyeball pinned on the employment ads to see what's going on in their career sector.  Maybe you just like to get a feel for how the employment situation is in a given geographic area.  Whatever the case, if you are one of those people, you've probably seen a few repeat employer names pop up week after week, month after month.

Whenever you see a particular employer posting an unusually high number of positions, or the same position for weeks on end, check something else:  the employer's growth aspects.

If the employer has not won any major (and I mean MAJOR) new contracts, isn't opening a new facility somewhere nearby, and isn't responding to cyclic or seasonal activity demand, start asking questions.  In many cases it's a sign that the workplace suffers from high turnover.  High turnover can be (and quite often is) a sign of a bad workplace environment, in which employees grow tired (or afraid) of it, and leave.  One particular health services technology company in our area posts over a dozen job openings every week, most of which are the same job opening.  Some of which have been reposted for over a year.  After asking around I've learned that employer is renown for treating workers badly and thus are always having to back-fill vacated positions.

Then again, if you're OK with high turnover, no worries.  Maybe all you are interested in is a fast buck.  A quick means to a paycheck, or something to hold you over until make the next jump.  That's fine. Everyone has their own agenda.  But if you are looking for something more long term, what then?

Where do you start?  You can start by asking trusted friends, co-workers, neighbors, and friendly folk at your nearest social establishments (pubs, restaurants, etc.).  Just ask "what do you know about (name-of-employer)?" and "are they a good place to work for?".  The range of responses will sometimes surprise you, and you may learn things you never expected.

As an interesting exercise, try this using your current employer's name.  It's one of the oldest, easiest, cheapest, yet overlooked marketing research a business can do on their own.

Read More

Mixing Oil and Water: Systems Engineering and Software Development

In all my years working this field we call "IT" I have never seen an environment where these two groups coexist cohesively and with a common goal.  Systems Engineering and Software Development.  Sure, they might get along well, and share working spaces, but as functional entities they typically exist in separate worlds, chasing their own beasts to slay.  And why not?  After all, they serve different purposes, for different masters (usually). They use different tools and techniques.  They often have very different reasons for doing things as well.

The Developers want to create and update things.
The Engineers want to implement and upgrade things.

Hmmm.  Those aren't that different after all.  Are they?  I know some folks would argue that engineers want to implement and "maintain" things, but maintenance is really an operations role, which in most cases falls into the hands of Systems Administrators (or "sysadmins" to use contemporary parlance).  Engineers want to engineer things.  Simple enough.  However, maintaining isn't really engineering, it's really maintaining or administering; keeping things moving along without interruption.

Developers want to create new things.  Write new code, new features, new widgets.  Add new capabilities or make the interface more "cool" and intuitive.  They don't want to maintain things any more than engineers do, even though they have to deal with bug fixes, patches, service packs and regression testing.  Life sucks.  Nobody said the gravy doesn't have lumps every now and then.  Engineers have to deal with those lumps too, especially when transitioning new things into the hands of the SysAdmins.  It's life (and it happens to pay pretty darn well, thank you).

So, if these two camps are so similar, and they often possess such awesome potential, when then are they not more often exploited towards a common goal?

Prologue

I'm writing this because this quasi-mythical world is precisely where I've found myself repeatedly over the past twenty-odd years.  You see, I started out as a draftsman (on the board, with sepia, paper and Mylar, thank you), and was part of the wave of folks in the 1980's who got corralled into the emerging world of CAD, or Computer Aided Design.  That led to customizing the CAD toolset, which sucked me into the world of software development and programming like drunk sailor in front of a Thai brothel (no, I was never in the Navy, nor have I ever been to Thailand, the phrase just seems to fit).

After years of that, I drifted into "mainstream" IT by way of helping an old friend implement SMS 2.0 in a large corporate environment (ok, he did 99% of the work, I just handed him some wrenches), but it was enough to turn on a light bulb in my head about the incredible potential of a networked environment, the tools, frameworks and protocols that make it possible to leverage a whole new level of capability and productivity on a much larger scale.  LDAP, ADSI, WMI, TCP/IP, SNMP, the Windows API stacks, Registry, Event logs, alert mechanisms, and so on.  Then came ever-increasing power and simplicity with enterprise databases (Oracle, SQL Server), and the arrival of web technologies.

Oh man, I was so there.  SO THERE. It was like a labor camp escapee wandering into a Ruth's Chris restaurant on "free dinner" night.

Even now, even when I get involved in another project to inject Development into Engineering, it's the exception, never the rule.  In most cases it creates such an oddity that neither camp gets offended, just more or less confused about the value.  That is, until the project starts to bear fruit.  Then I get Engineers asking about the development aspects, and Developers asking about the infrastructure engineering aspects.  It's kind of like the old Reese's Peanut Butter Cup ads from the 1980's.

Continuing On...

As Yogi Berra might have said, I've been doing the same thing over and over again, only differently each time.  I am handed some problems to solve, which span multiple systems, multiple departments, multiple environments, multiple business cultures, multiple security realms, multiple personalities, and asked to somehow build something of a bridge across all of it to get the traffic (information) moving.  I don't really have name for it.  Some call it BPA, or Business Process Automation, or Systems Automation, or Data Mining (not a really great term).  Some don't know what to call, so they just give a description like "that stuff Dave is working on".  But whatever it might be called, it's where these two worlds intersect.  And the result is quite a lot like the Super Hero Action League touching their power rings together (only without the "shazamm!!!" sound effect).

A lot of vendors would argue you can solve almost every problem with an out-of-the-box solution, but anyone who's worked in this realm for more than a decade knows that's as realistic as pocket-sized nuclear fusion power.  Maybe someday.  Maybe someday.

Putting this a slightly different way: Any time you implement something to abbreviate the steps required to perform a repetitive task, it most likely involves writing a script, a program, or configuring a bunch of options in a widget to enable this to happen.  This borders on Software Development.  With the advent of PowerShell, especially the concerted effort behind its proliferation, we're seeing a surge in the popularity and prevalence of SysAdmins writing scripts to handle chores that were once considered off limits.  Maybe it was because of a bad perception about VBscript or Batch scripting?  Maybe it's because PowerShell is becoming so intrinsically part of more and more Microsoft (and VMware) products?  Maybe it's because of it's Spartan syntax and brevity (at the command line, not always so within cmdlets)?

I've met so many people in this line of work who have strong feelings about "best practices".  Many are of the opinion that unless there's a ready-made product to do something, it shouldn't be done by other means.  This is not only short-sighted and foolish, it's downright disingenuous towards the employer.  If there exists a means to solve a problem now, even if it requires a little elbow grease, you owe it to yourself, your employer, and your customers to consider it.  Especially if this involves existing means which are "free" (provided with the products already purchased: Windows, etc.)

Microsoft didn't provide this insanely broad inventory of API's, protocols, command tools, and utilities for talking about at dinner parties.  They were provided for your benefit, and the benefit of their customers to build things to do more than they do "out of the box".   Don't be afraid.  Don't fear change.  The "Soft" in Software was Charles Babbage's gift to all of us that freed us of the Iron shackles to hardware.  It was intended, from the very start, to be "changeable".  To allow us to adapt processes and capabilities to meet newer challenges.

If you ever, and I mean EVER, enjoyed building things as a child, whether it be Lego's, model kits, model rockets, Linkin Logs, or even stacking wooden blocks, you should find a lot to enjoy building things on the Windows platform.  Heck, any platform to be honest, but for this discussion I'm thinking along the lines of Windows.  It seems that either a lot of grown-ups forgot how much fun that experience was, or they never got into it in the first place.  If you consider yourself an Engineer, and ever wondered what it was that Developers found appealing in their work, it's the fascination with putting things together from scratch and seeing them perform when finished.  Engineers get that sensation as well, but at a higher level in the logical technology stack.

In most cases, Engineers are working with components which were provided by Developers, but this is where it often stands and never changes.  There's still room for development during the Engineering phase.  When the out-of-box components don't hit every note in the song, it can do wonders to get a Developer involved.  In most cases, if the right people are involved, the song comes out even better than expected and ideas start popping out for new potential and new directions.

Conclusion

IT is all about change.  It's an intrinsic part of the fabric of technology.  To fear it is to refuse the absolute purpose in and of itself.  Nothing demonstrates, or proves, the value in embracing this more than seeking a convergence between Development and Engineering. Nothing.  The teaming of the "thinkers" with the "do-ers" is the ultimate way to push it as far as it can go.  As long as these two worlds are kept isolated, or at the very least, un-involved, the less we take this profession seriously and the more handicapped we keep our employers as a result.

Read More

Well. There Goes the Neighborhood

I had planned on retiring from blog writing for the past year.  I've given it up before, back in 2008 actually, but came back to it for a variety of reasons.  This time it's a little different.  Is it because I was inundated with e-mail begging me to continue on?  No.  Is it because I really didn't want to retire it in the first place?  Not really. Is it because I'm going to make a pitch for revenue?  Oh, HELL no.  It's actually because someone at fairly large company asked me to keep going as part of a beta program.  I'm not permitted to say any more than that so don't ask, and even if you asked, I wouldn't tell, and even if I told you, it would push you into a coma from shear boredom.

New Ground Rules:

1. No more shotgun blast posts. Once or twice per week at most, but probably much less than that.

2. Topic focus:  The philosophical aspects of merging Software Development with Systems Engineering and Architecture with the world of Business and Social engineering.

3. Whatever I want to say beyond that.

Clear enough?

So, let me revisit some numbers.  Where is the blog at with respect to traffic statistics?  As of today, this blog as drawn 127,500 page views since May 2009 (the farthest back the new statistics engine will report).  The blog was brought back online in December 2007 after a brief hiatus from an earlier start in 2006.

The peak traffic was in November 2011, at around 25,000 page views.  January 2012 is somewhere around 10,000, which is expected.

I have some articles lined up for posting soon.  Because hardly anyone has spoken up to request topics or general interests, I'm picking my own (big surprise).  This should be interesting since I have no idea whether anyone (you) will care.  That doesn't matter.  The goal is to (A) help out a team of nice folks asking for my help, and (B) exercise my brain while I recover from chemo treatments (I'm doing very well, thank you).

Stay tuned.

Read More

Book News: Grinding Gears / Software Repackaging and Deployment for the Windows Platform

Relax, I'm still in blog retirement.  But I did promise earlier that I would be posting an update on my next book and that time has now come.  This is now my seventh (7th) book published, and is the culmination of about a year of compiling notes and material and drafts.  I've been close to publishing it several times, but then decided to scrap it and start over because I wasn't happy with it.  I think I am happy with this one.  At this point I have no plans for another book, but that could change.

The book is called "Grinding Gears:  Software Repackaging and Deployment for the Windows Platform":

It's not just about packaging, or scripting, or AdminStudio, or Configuration Manager or any particular product or technology.  It's about the mindset, rationale, techniques and philosophy behind methods of packaging, repackaging, testing, and deploying software.  I've also covered some human aspects, business rationale, and so on.  Here's the Table of Contents...

I also wanted to thank a lot of people for helping me and inspiring me...

This book is currently in review by Amazon, and will be available for purchase very soon.   It will be published exclusively for Amazon Kindle at $10.99 (USD), and available for Amazon customers in UK, France, Germany, Spain and Italy.  Remember, you don't need a Kindle to read Kindle e-books.  You can read them on almost any mobile device, tablet, desktop or laptop computer using one of their Reading Apps, or using their Cloud Reader as well.

Meanwhile, you can check on the availability by visiting my Amazon page at http://www.amazon.com/David-M.-Stein/e/B006BHXOFE/ref=ntt_athr_dp_pel_pop_1

Read More

Happy New Year!

It would be rude of me not to wish all of you a Happy and Safe New Year and I hope it is prosperous and fun for all of you and your friends and families!  Take care!

Read More