PowerPivot Expo – Today
Thanks to everybody who signed up to attend our eight virtual sessions on PowerPivot! We’re kicking off the event at 9 a.m. Pacific, so if you forgot to register, come on in and join in all the Business Intelligence-focused fun.
Keeping Current in a Rapidly Changing World
It’s time to take control of maintaining your own skills; no longer can you afford to wait for your employer to keep you current with recent or emerging technologies.
Let’s face it; you and your employer often have differing motives when it comes to technology.
An employer may make a large investment in technology. At that point the employer focuses on getting a return for their investment. Unless you can demonstrate why moving to a newer version or different platform is not disruptive, how it provides a market advantage, or how it will reduce cost, they are not going to be interested. Frankly, this is a good business decision.
But what happens when they don’t keep current for too long? Your skills, as you continue to work there, become obsolete, or at a minimum, lower in demand. Depending on the employer, that may not be a bad thing. My experience has been that very few companies do not have periods when they have to reduce staff.
When you become one of the individuals asked to leave a declining company, and your skills, while perfect for your old employer, are no longer sought, what are you to do? There’s nothing more depressing than looking on job postings only to find you don’t have any, or enough of the skill sets being requested.
Wake up! At that point you have already waited too long. Only you are responsible for your skills. So, be responsible.
Monday I’ll be providing some ways you can work on extending your skills at a reduced cost. In the meantime, if you have some ideas or experiences of your own, please send them in to btaylor@sswug.or to share with our readers.
Reader Comments
Inheritance vs, Composition
David Writes:
Wanted to throw a bit of fuel on the fire.
In my experience, a detailed inheritance hierarchy doesn’t really help a new software project, and is mostly a cargo-cult tool for programming taxonomists.
Inheritance is intended to improve code reuse, allow the child object to treat all methods and data structures it does not want/need to alter as a “black box” only accessed through its interface, and allow methods that understand a parent object operate on a child object.
How does this compare to Composition? Composition also allows for code reuse, so the first advantage is neutralized. Composition allows “black box” access, so that is also neutralized. Composition does not allow methods unaware of the “composed” object to work with it, so Inheritance appears to have a point in its favor, there.
But, Inheritance also allows a child to override a parent object’s method or data structure, and that capability means that whatever method is attempting to use the child as if it were the parent could blow up because the child altered the behavior/structure in a way unexpected by the method using the object.
Essentially, what makes a duck a duck? Is it the distinctive quack? (Well, what about whispering ducks?) Is it the orange bill or waddling walk? (Well, what about geese?) Is it the water resistant solid-colored feathers? (Well, what about mallard ducks?) Basically, even with things we think must have a set of core distinctive features and actions, there may be exceptions that are otherwise mostly like the whole and are classified with it.
This same confusion can occur in a larger group of programmers using inheritance, especially on a new software project. A base class is defined containing “core” functionality, and different programmers work on different objects which inherit from it. These objects, as they are different, have different purposes (say, FileSystem accessors), and for some of them, some of the “core” functionality isn’t needed (a Joliet filesystem accessor does not need any write capabilities, for instance) and they make the functionality inherited do nothing. Another programmer is working on an object that will use these objects, and assumes that all base class functionality exists, but then the software crashes (when a foolish user points the Save dialog at their DVD-ROM drive) because one of the objects didn’t behave as expected.
There is a better way to do this: Composition and Interfaces. Define an interface that any compliant object must implement and then let the object do whatever it needs to implement it (which may include forming a composition with other composed objects implementing an interface).
Is Composition with Interfaces a panacea? No. With this, each object created will require an essentially unknown number of memory allocations to initialize/destroy, so for very high performance code after the true hierarchy of the software is known, it can make sense to translate the composition into a rigid inheritance structure so the compiler can know how to allocate/deallocate the object’s memory in one step.
But when you’re first developing the software, inheritance can be a straightjacket that can induce bugs if the scope of the entire program is not known to every programmer on the team.
Cheers,
Ben
$$SWYNK$$
Intro to Analysis Services Class – Next Friday
SSWUG.ORG and Pragmatic Works have come together to develop another in-depth, online course!
Brian Knight, course instructor and SQL Server MVP, will take you from the ground-up, teaching you the fundamental skills you need to develop and deploy SQL Server Analysis Services (SSAS) solutions and present this new data to your end users.
Featured Article(s)
Information Architecture and Governance – What’s New for SharePoint 2010 (Part 1)
We’ll look at what is new in Microsoft guidance for SharePoint 2010: both from the perspective of architecture and framework, and will present an overview of what resources Microsoft provides to set you up for success.
Featured White Paper(s)
Query Tuning Strategies for Microsoft SQL Server
Written by Quest Software
When you’re looking for a reliable tool to diagnose … (read more)