Last time, I posted about an empowerment ratio, which can be an indicator of how much a company trusts its people to effect improvements in an organization's products and processes. Another concept I see that leads to difficulties for people is the decision-consequence gap. This term refers to the distance between a decision-maker and the consequences of his or her decisions.
When the gap is narrow, the decision-maker is cognizant of how his or her strategy is working; he knows whether unforeseen factors have made executing the plan more challenging and is aware of how subordinates are carrying out the tactics in meeting a plan's goals.
When the gap is wide, the decision-maker lives in a vacuum and tends to take credit for success and pass blame for failures often without understanding how results are achieved or missed.
This gap is a big factor in leadership, and most leaders seem to misunderstand or not care about it. It's not just in IT either, and dysfunction is visible within this concept across top leadership in all industries. And wide decision-consequence gaps often lead to poor empowerment ratios.
It's a harsh recipe especially in software development too, when functional owners and project managers are given strategic and tactical control over non-functional elements. Although not all will make mistakes here, under the duress of time constraints there is often a push to favor speed over quality. Non-functional concerns will be given little priority despite the advice of the developers presiding over the construction.
If you've ever supported poorly designed and poorly implemented software, then you are quite familiar with this already. The people that decide a team will cut corners to make a date are not the same people who have to support it and work the production support load.
The project manager's common refrain here is that if developers are left to their own devices, the product will never ship. I agree that developers who care and are perfectionists may draw the development cycle longer than is comfortable for the business. And it is often true too that developers, in the interest of pleasing management, will comply in promoting a shoddy release to make a date.
But what I hope for in a better and more mature IT world is not perfection. It is that we collectively strive for something better than the C-minus level software most corporations deal with now. Can we maybe compromise and get to a B grade? The difference between a C-minus and a B would be perhaps that some routines feature hard-coding, but that routine is properly isolated in a method that can be easily tested and refactored. Or that we put more eyeballs on our database structure so that common pitfalls don't make it into production and compromise future enhancement and refactoring efforts. Or that we not short the concepts of testing and training, so that fewer "diaper change" type of requests get turned into weekly flurries of productivity-and-morale-sapping help requests. Or that user interfaces aren't so awful as to make our users cringe when they have to work with our systems.
None of the above suggestions are terribly expensive and a lot of it is good preventative maintenance and best practice. Yes, there will be a cost somewhere, probably in time invested up front. But you can't read a magazine article about agile and then decree your teams will start using it and expect immediate benefits if you haven't empowered them to write software that is properly objectified and can be tested or maintained without massive effort. And you won't understand any of these concerns if you suffer from a sizable decision-consequence gap.
Friday, March 29, 2013
Thursday, March 21, 2013
The Empowerment Ratio
It's really hard to be a grunt in IT. It's even hard to be a manager or leader in IT. At least, it is if you care and really want to do more for your users and clients and your teams. As this industry advances you'd think we'd collectively improve based on lessons learned applied institutionally. It doesn't really happen like that though.
Yes, we do see some improvements. Since I started working in IT, several things are better than they've ever been: user interfaces, databases, source control, languages, tools, and some processes. And of course the hardware is amazing now and just getting faster and smaller and sometimes practically invisible: virtualization is a very useful tool. But even with all those trappings of the software development space getting better, the people parts of the industry continue to exhibit tremendous and apalling flaws contrary to the ideals of such intellectual pursuits.
One of the things that has most frustrated me, and I'm betting it dogs many of my industry brethren, is a concept I call the power-responsibility ratio, or the empowerment ratio. I mention it in this post because it's a concept that will be used in a future post. It's a problem not just in IT, but in all industries. The power-responsibility ratio is the rating of power a person has to effect change relative to the amount of responsibilty they have over a particular process or domain.
Example: the typical IT support team has responsibility for an application's operation. This includes being the first point of contact for anything that can go wrong: network infrastructure, hardware, software defects, user error, process error, data error, interfaces, cross-system discrepancies and reconciliation, bug fixes, new features, project management, data fixes, source control, documentation, and probably a dozen other things I've forgotten to mention.
Now that's a lot of responsibility. But if any one of those factors in the system ecology isn't efficient, it can affect the total productivity of the team. So if there's a problem, the team just changes it right? Not exactly. IT grunts are increasingly beholden to productivity sapping cruft and dense processes invented by people that don't have to suffer the consequences of these process deficiencies.
Want to change to faster hardware, you'll have to get permission from someone else. Want to move to a more efficient document system? Get permission from someone else. Is there a particular user that's proving intransigent about using the system correctly and doesn't want to learn, but continues to create problems? Good luck replacing him. Someone on your own team proving unwilling to follow the best practices everyone else is? Didn't you hear corporations don't fire people for incompetence anymore, they only do it for political incorrectness. Want to upgrade the software to the latest version of a framework? No can do, the project manager thinks that effort is wasted because it's not part of the business needs. Think you found a way to reduce the overhead in those data fixes that are killing the team's capacity for more strategic work? After filling out forms in triplicate, you find out it was denied because the powers that be just don't feel it's that important; powers of course who don't have to suffer with processing the repeated data fixes.
I'm being a little facetious here because not all management says "no" to everything, just most. But the point I'm making here is not about having to ask, though that's part of the inefficiency of it all. It's more that IT workers may be the least empowered people in modern organizations. Accounting has a lot of power because it manages finances and in the case of some controllers, accounting actually has to take managerial responsibility for some regions and therefore must understand the business. IT is similar in that it learns about the business and the data that flows through a company, but do IT people have the power of accountants? Not really. R&D, they're usually getting to do things that help the company and as they're seen as a part of the company's core business and its future, so they are deservedly respected and have some influence. HR certainly seems to have garnered a big part in organizations now. Sales and marketing? Please. But IT is expected to be on-call 24x7 and can't get approval for even simple changes.
That's an incredibly frustrating position to be in: You hold significant responsibility over a domain but have very little power to improve it.
What's really sad about this is that the solution has long been documented. In the military, effective leaders know they have to trust the boots on the ground to be able to manage their unique situations, and those boots need to be able to make changes efficiently, or at least as efficiently as possible in the behemoth military. [Note that I'm not saying the military is all good here, it's certainly had its share of gaffes, key leaders are often clueless, and it is hardly a universal exemplar of a properly applied empowerment ratio. But selected groups, like the Special Forces, have figured it out.] And in many management books the concept of empowerment has been a popular one. It's not like this is some secret that can only be implemented with excruciating pain or arcane spell casting. The solution is a simple thing, a single word: trust.
A lot of organizations have a long way to go before they will be able to take advantage of truly superior IT.
Yes, we do see some improvements. Since I started working in IT, several things are better than they've ever been: user interfaces, databases, source control, languages, tools, and some processes. And of course the hardware is amazing now and just getting faster and smaller and sometimes practically invisible: virtualization is a very useful tool. But even with all those trappings of the software development space getting better, the people parts of the industry continue to exhibit tremendous and apalling flaws contrary to the ideals of such intellectual pursuits.
One of the things that has most frustrated me, and I'm betting it dogs many of my industry brethren, is a concept I call the power-responsibility ratio, or the empowerment ratio. I mention it in this post because it's a concept that will be used in a future post. It's a problem not just in IT, but in all industries. The power-responsibility ratio is the rating of power a person has to effect change relative to the amount of responsibilty they have over a particular process or domain.
Example: the typical IT support team has responsibility for an application's operation. This includes being the first point of contact for anything that can go wrong: network infrastructure, hardware, software defects, user error, process error, data error, interfaces, cross-system discrepancies and reconciliation, bug fixes, new features, project management, data fixes, source control, documentation, and probably a dozen other things I've forgotten to mention.
Now that's a lot of responsibility. But if any one of those factors in the system ecology isn't efficient, it can affect the total productivity of the team. So if there's a problem, the team just changes it right? Not exactly. IT grunts are increasingly beholden to productivity sapping cruft and dense processes invented by people that don't have to suffer the consequences of these process deficiencies.
Want to change to faster hardware, you'll have to get permission from someone else. Want to move to a more efficient document system? Get permission from someone else. Is there a particular user that's proving intransigent about using the system correctly and doesn't want to learn, but continues to create problems? Good luck replacing him. Someone on your own team proving unwilling to follow the best practices everyone else is? Didn't you hear corporations don't fire people for incompetence anymore, they only do it for political incorrectness. Want to upgrade the software to the latest version of a framework? No can do, the project manager thinks that effort is wasted because it's not part of the business needs. Think you found a way to reduce the overhead in those data fixes that are killing the team's capacity for more strategic work? After filling out forms in triplicate, you find out it was denied because the powers that be just don't feel it's that important; powers of course who don't have to suffer with processing the repeated data fixes.
I'm being a little facetious here because not all management says "no" to everything, just most. But the point I'm making here is not about having to ask, though that's part of the inefficiency of it all. It's more that IT workers may be the least empowered people in modern organizations. Accounting has a lot of power because it manages finances and in the case of some controllers, accounting actually has to take managerial responsibility for some regions and therefore must understand the business. IT is similar in that it learns about the business and the data that flows through a company, but do IT people have the power of accountants? Not really. R&D, they're usually getting to do things that help the company and as they're seen as a part of the company's core business and its future, so they are deservedly respected and have some influence. HR certainly seems to have garnered a big part in organizations now. Sales and marketing? Please. But IT is expected to be on-call 24x7 and can't get approval for even simple changes.
That's an incredibly frustrating position to be in: You hold significant responsibility over a domain but have very little power to improve it.
What's really sad about this is that the solution has long been documented. In the military, effective leaders know they have to trust the boots on the ground to be able to manage their unique situations, and those boots need to be able to make changes efficiently, or at least as efficiently as possible in the behemoth military. [Note that I'm not saying the military is all good here, it's certainly had its share of gaffes, key leaders are often clueless, and it is hardly a universal exemplar of a properly applied empowerment ratio. But selected groups, like the Special Forces, have figured it out.] And in many management books the concept of empowerment has been a popular one. It's not like this is some secret that can only be implemented with excruciating pain or arcane spell casting. The solution is a simple thing, a single word: trust.
A lot of organizations have a long way to go before they will be able to take advantage of truly superior IT.
Saturday, March 16, 2013
Corporate America, You're Doing it Wrong: Part 2
So how do you fix it? Last post, there were three things that have gotten pooched: products, employees, and clients.
Let's fix the most important part first.
According to a Google search [full disclosure: blogspot is owned by Google], Drucker indeed coined the phrases "cost center" and "profit center." And yes, he used the terms to split a company's resources into two camps; the revenue generators and...the rest. And his book was probably on the corner of a lot of coffee tables in a lot of executive suites, so of course everyone believed it. It wasn't totally ridiculous and Drucker presented it professionally, so there you have it.
But years after that, Drucker himself relented from this divisive concept, calling it the worst mistake he'd made. He offered a correction and identified that there is really only one profit center, that being the paying customer. Everyone else, from the CEO down, is a cost center. Painful though it may be for a lot of fat heads to accept, this new line of thought from Drucker makes more sense and is much more truthful about the whole business equation. As I said in an earlier post, if an executive thinks IT workers can easily be replaced by remote resources in India, or better yet, robots, then the other side of that is true too. An Indian PhD in business ought to be a lot less expensive than the typical American executive (and possibly a lot smarter).
Every bit of effort in a company by all its resources should be about ultimately serving the customer. Not the board. Not the executives. Not the rest of the employees.
Make great product; not an ok one, not a good one, make a great one. Then stand behind it and fix it, but make a product good enough that your customer support and production support costs are low because it works right the first time. Charge a fair price, adjusting for competition. I know, the competition includes companies from China that don't respect intellectual property so they copy your product and use cheap labor to build clones for cheap...and those damned customers will buy them. First, fix that attitude because the customers are doing exactly what you'd do if someone gave you two comparable products and had a lower price on one of them. Second, compete the best way you can: with innovation. They can copy your product but they can't quickly copy your initiative, your customer knowledge, and your customer relationship. Keep innovating and they will always be playing catch-up. How to innovate? More on that when we fix your employees.
But putting the customer first isn't how it is. Maybe in a few companies. Maybe in the past it was more like that. But not in the contemporary world. Stockholders only care about returns, and that causes boards to put pressure on getting results faster and faster. This in turn leaves company leaders to resort to putting the most obvious metric at the front of all decisions, project evaluations, and employee evaluations: the date. Get it done by a date. If it's imperfect, thats ok, we'll fix it later. And thus is endorsed a philosophy of not accepting technical debt as a necessary evil but as a strategic option. It comes from the top and it works its way into all ranks and pretty soon delivering broken shit or half-assed shit is ok.
Of course, not all companies have the same leeway here. Compromised safety standards will injure people and ultimately sales. Established companies like Toyota and BP would therefore never do such corner-cutting for the sake of short-term sales.
Looking at these pressures, you have to wonder if perhaps they're at least part of the reason Dell has chosen to revert from being a public company back to a private one. Dell offers another example here; at one time the company tried to outsource all its technical support to India, but backlash from customers caused Dell to retain US technicians for corporate customers. In the latter case, Dell recognized it had to keep its largest revenue generators satisfied. Of course the rest of the little customers got screwed, but at least some of this corroborates the Drucker correction. But it remains to be seen what Dell will do with this recovered initiative.
"The customer comes first" is an old tenet of business. For a lot of companies it's also a forgotten one.
You're doing it wrong.
Let's fix the most important part first.
Clients
A lot of Corporate American heads like to say, "I'm a profit center along with my vaunted staff of silver-tongued gilded warrior salesman. Even Peter Drucker said so. The rest of you are shit, er, I mean, cost centers."According to a Google search [full disclosure: blogspot is owned by Google], Drucker indeed coined the phrases "cost center" and "profit center." And yes, he used the terms to split a company's resources into two camps; the revenue generators and...the rest. And his book was probably on the corner of a lot of coffee tables in a lot of executive suites, so of course everyone believed it. It wasn't totally ridiculous and Drucker presented it professionally, so there you have it.
But years after that, Drucker himself relented from this divisive concept, calling it the worst mistake he'd made. He offered a correction and identified that there is really only one profit center, that being the paying customer. Everyone else, from the CEO down, is a cost center. Painful though it may be for a lot of fat heads to accept, this new line of thought from Drucker makes more sense and is much more truthful about the whole business equation. As I said in an earlier post, if an executive thinks IT workers can easily be replaced by remote resources in India, or better yet, robots, then the other side of that is true too. An Indian PhD in business ought to be a lot less expensive than the typical American executive (and possibly a lot smarter).
Every bit of effort in a company by all its resources should be about ultimately serving the customer. Not the board. Not the executives. Not the rest of the employees.
Make great product; not an ok one, not a good one, make a great one. Then stand behind it and fix it, but make a product good enough that your customer support and production support costs are low because it works right the first time. Charge a fair price, adjusting for competition. I know, the competition includes companies from China that don't respect intellectual property so they copy your product and use cheap labor to build clones for cheap...and those damned customers will buy them. First, fix that attitude because the customers are doing exactly what you'd do if someone gave you two comparable products and had a lower price on one of them. Second, compete the best way you can: with innovation. They can copy your product but they can't quickly copy your initiative, your customer knowledge, and your customer relationship. Keep innovating and they will always be playing catch-up. How to innovate? More on that when we fix your employees.
But putting the customer first isn't how it is. Maybe in a few companies. Maybe in the past it was more like that. But not in the contemporary world. Stockholders only care about returns, and that causes boards to put pressure on getting results faster and faster. This in turn leaves company leaders to resort to putting the most obvious metric at the front of all decisions, project evaluations, and employee evaluations: the date. Get it done by a date. If it's imperfect, thats ok, we'll fix it later. And thus is endorsed a philosophy of not accepting technical debt as a necessary evil but as a strategic option. It comes from the top and it works its way into all ranks and pretty soon delivering broken shit or half-assed shit is ok.
Of course, not all companies have the same leeway here. Compromised safety standards will injure people and ultimately sales. Established companies like Toyota and BP would therefore never do such corner-cutting for the sake of short-term sales.
Looking at these pressures, you have to wonder if perhaps they're at least part of the reason Dell has chosen to revert from being a public company back to a private one. Dell offers another example here; at one time the company tried to outsource all its technical support to India, but backlash from customers caused Dell to retain US technicians for corporate customers. In the latter case, Dell recognized it had to keep its largest revenue generators satisfied. Of course the rest of the little customers got screwed, but at least some of this corroborates the Drucker correction. But it remains to be seen what Dell will do with this recovered initiative.
"The customer comes first" is an old tenet of business. For a lot of companies it's also a forgotten one.
You're doing it wrong.
Friday, March 15, 2013
Corporate America, You're Doing it Wrong
I know, you're looking at the title of the post and rolling your eyes at me being a cynical bastard again. Well, you can tell yourself that if you want. But you are doing it wrong...it's why I became a mercenary. I figured out the game and now I play it instead of letting it play me.
The More Things Change the More they Stay the Same
Well, not really. I'm still being exploited for someone else's profit, but it's better than it used to be. I've given up dreams of institutional achievement and only two constituents really matter anymore: my family and my clients. The rest of you are just infrastructure, trying to sell me on the golden rung at the top of a ladder that I know is made of pyrite.
Your Job is to take Care of Products, Employees, and Clients
Oh there's some gold there all right, but you have to sell your soul to get it, not by making a deal with the devil, but by complacently doing the same c-level executive horseshit that most of them do. You might not even be doing it intentionally but you're destroying dreams by the thousands by succumbing to the typical corporate insensibilities. Your constituent is just one entity: you. You will blame the stockholders and board of directors for making you do stupid things like purposely putting your product quality at risk, your employees in the crapper, and your clients last in the food chain. That excuse doesn't wash; if you are going to blame the stockholders and the board and then take profits, you don't understand leadership. And that's your primary job. You don't build widgets or beat the pavement anymore; you're supposed to be a strategic thinker that builds the company's future with keen decisions, reliable relationships, a vision for the future, and respect for the past. But nope. It's all about you, and it's gutless.
You're doing it wrong.
The More Things Change the More they Stay the Same
Well, not really. I'm still being exploited for someone else's profit, but it's better than it used to be. I've given up dreams of institutional achievement and only two constituents really matter anymore: my family and my clients. The rest of you are just infrastructure, trying to sell me on the golden rung at the top of a ladder that I know is made of pyrite.
Your Job is to take Care of Products, Employees, and Clients
Oh there's some gold there all right, but you have to sell your soul to get it, not by making a deal with the devil, but by complacently doing the same c-level executive horseshit that most of them do. You might not even be doing it intentionally but you're destroying dreams by the thousands by succumbing to the typical corporate insensibilities. Your constituent is just one entity: you. You will blame the stockholders and board of directors for making you do stupid things like purposely putting your product quality at risk, your employees in the crapper, and your clients last in the food chain. That excuse doesn't wash; if you are going to blame the stockholders and the board and then take profits, you don't understand leadership. And that's your primary job. You don't build widgets or beat the pavement anymore; you're supposed to be a strategic thinker that builds the company's future with keen decisions, reliable relationships, a vision for the future, and respect for the past. But nope. It's all about you, and it's gutless.
You're doing it wrong.
Friday, January 06, 2012
We are all script kiddies now
The Way We Were
So if you have read earlier entries in the blog, you know that I once reviewed learning styles as categorized by David Kolb. They were all lengthy thoughts on how each person learns differently and how each person may respond better to certain teaching styles. And I think there is something to what was said there.
But there was a news report not long ago about how Google (or rather the "internet search"; let us not get into the habit of calling all photocopies "Xeroxes") is changing the way our brains work, by wiring them to go for the instant knowledge gratification. The thought is that rapid information access is making short term memory less effective because we use the internet as a crutch. And I thought at the time, "Oh maybe, but that's only for idiots that learn programming by reading those stupid Dummies books. Proper learners like me will always take a class and read quality books written by guys like Steve McConnell and Andrew Troelsen, and take our time learning and refrain from writing code until we have a body of knowledge about the language."
The Calculator Discovered
Then I started picking up Linux and PHP and MySQL. And when I ran into problems, I found that under desire to complete tasks I couldn't help but go to the internet for rapid information access. And then I remembered what I used to think about learning, and I realized I was the idiot.
I was using the internet to glean knowledge from others, even so much as stealing functional and useful scripts through the browser. I could get things done fast, and while I had to use my brain, it was significantly less work than forging painfully through arcane documentation and numerous trial and error sessions fighting with the script parser. Shortly after that, I realized I had become a script kiddie. And I liked it.
It was like I'd become Bradley Cooper's character in Limitless; I could pull down references from all over the world in seconds. I could make my bash script in a fraction of the time that it would have taken to build it from scratch by using what others had done. I could search for what I wanted to do via MySQL's mysqladmin, and I could get exactly or almost exactly what I needed quickly. It felt a little like cheating, but I was getting real work done. It sucks to be wrong, but being a script kiddie has its benefits, not the least of which is a material immediacy that matches the American culture's thirst for NOW.
You Gain more Wisdom from Failure than Success
AND YET...
Isn't there something missing in the new way of learning? I don't mean the obvious things like, "What the heck are you going to do on a camping trip when you're an automaton that can't tie shoes without internet help, you don't have connectivity, and a bear is chasing you?" I mean things like what Carl Feynman and Michelle Feynman were probably thinking about when they came up with the title of the book about Richard Feynman, The Pleasure of Finding Things Out. Smarter guys than me have said that sometimes the journey is more important than the destination. No one seems to care if you finish in second place, but if you learned a boat load on the way there, isn't that enrichment worth more than a red ribbon (or blue if you're in Canada [thanks, quick internet search!])?
In programming, when we copy a script or follow a script that doesn't also explain why something is the way it is, we lack the history of the issue and thus the context that helps us understand why we do the things we do, or perhaps that gives us the knowledge we need to know when something is extraneous and can be removed or changed for efficiency.
But does all of that even matter anymore? Software development, except in the very few places that truly revere quality over deadlines, has been transformed by corporations into the world's second sloppiest profession (the first is law. Sit on a jury or even jury panel selection sometime and then tell me I'm wrong). I can only think of one development shop that dared to say, "Design is law," and it is out of business. Two other shops have a quality focus, and even they're changing. Id Software and Apple Computer both like to say, "It'll be done when it's done." Id's latest releases might be technical marvels, but they've proven Id is more about programming than game development. And Apple, although one of the best at managing the convergence of hardware and software, has nevertheless taken criticism recently for an underwhelming iPhone 4 release, perhaps finally showing that even they can succumb to market pressures to put date before quality and innovation.
We are all Script Kiddies now
The world moves at pace that I've heard referred to as "internet time" or "web time". Example: "Two years in web time is an eternity." Given that, can developers afford a classical style of learning? For that matter, are calls for educational reform just about class sizes and getting teachers more money, or are they also considering the way the internet is changing the way we learn and calling for a major paradigm shift in the way we teach?
Another report I've heard is that our youth today may seem superficially proficient with technology, but that while there are indeed some brilliant coders in their ranks, there are even more that are actually just comfortable "users" of technology, rather than masters of it. They can dig into menus and launch apps with the best of them and can seem, and are, supremely functional with their technology. They can text at lighting speeds, slap photos onto facebook in a heartbeat, and find a nearby restaurant on Google Maps, but they can't replicate the tech and most of them probably are as lost as their elders at configuring items in the deep recesses of the sub menus. It reminds me of the Issac Asimov story about the society in which everyone used calculators and only one person knew how to perform math by hand; he killed himself under the burden of the knowledge.
In the end, is becoming a script kiddie a turn to being a cheap, lazy programmer or is it just being an efficient one? Is it simply accepting that this is the way the world works and that you'd better adjust to compete? The truth is somewhere between the extremes, where it usually is. But I fear more people are turning to the script kiddie way and that it can lead to side effects, and a whole different kind of "dependency injection", that we're not preparing for.
So if you have read earlier entries in the blog, you know that I once reviewed learning styles as categorized by David Kolb. They were all lengthy thoughts on how each person learns differently and how each person may respond better to certain teaching styles. And I think there is something to what was said there.
But there was a news report not long ago about how Google (or rather the "internet search"; let us not get into the habit of calling all photocopies "Xeroxes") is changing the way our brains work, by wiring them to go for the instant knowledge gratification. The thought is that rapid information access is making short term memory less effective because we use the internet as a crutch. And I thought at the time, "Oh maybe, but that's only for idiots that learn programming by reading those stupid Dummies books. Proper learners like me will always take a class and read quality books written by guys like Steve McConnell and Andrew Troelsen, and take our time learning and refrain from writing code until we have a body of knowledge about the language."
The Calculator Discovered
Then I started picking up Linux and PHP and MySQL. And when I ran into problems, I found that under desire to complete tasks I couldn't help but go to the internet for rapid information access. And then I remembered what I used to think about learning, and I realized I was the idiot.
I was using the internet to glean knowledge from others, even so much as stealing functional and useful scripts through the browser. I could get things done fast, and while I had to use my brain, it was significantly less work than forging painfully through arcane documentation and numerous trial and error sessions fighting with the script parser. Shortly after that, I realized I had become a script kiddie. And I liked it.
It was like I'd become Bradley Cooper's character in Limitless; I could pull down references from all over the world in seconds. I could make my bash script in a fraction of the time that it would have taken to build it from scratch by using what others had done. I could search for what I wanted to do via MySQL's mysqladmin, and I could get exactly or almost exactly what I needed quickly. It felt a little like cheating, but I was getting real work done. It sucks to be wrong, but being a script kiddie has its benefits, not the least of which is a material immediacy that matches the American culture's thirst for NOW.
You Gain more Wisdom from Failure than Success
AND YET...
Isn't there something missing in the new way of learning? I don't mean the obvious things like, "What the heck are you going to do on a camping trip when you're an automaton that can't tie shoes without internet help, you don't have connectivity, and a bear is chasing you?" I mean things like what Carl Feynman and Michelle Feynman were probably thinking about when they came up with the title of the book about Richard Feynman, The Pleasure of Finding Things Out. Smarter guys than me have said that sometimes the journey is more important than the destination. No one seems to care if you finish in second place, but if you learned a boat load on the way there, isn't that enrichment worth more than a red ribbon (or blue if you're in Canada [thanks, quick internet search!])?
In programming, when we copy a script or follow a script that doesn't also explain why something is the way it is, we lack the history of the issue and thus the context that helps us understand why we do the things we do, or perhaps that gives us the knowledge we need to know when something is extraneous and can be removed or changed for efficiency.
But does all of that even matter anymore? Software development, except in the very few places that truly revere quality over deadlines, has been transformed by corporations into the world's second sloppiest profession (the first is law. Sit on a jury or even jury panel selection sometime and then tell me I'm wrong). I can only think of one development shop that dared to say, "Design is law," and it is out of business. Two other shops have a quality focus, and even they're changing. Id Software and Apple Computer both like to say, "It'll be done when it's done." Id's latest releases might be technical marvels, but they've proven Id is more about programming than game development. And Apple, although one of the best at managing the convergence of hardware and software, has nevertheless taken criticism recently for an underwhelming iPhone 4 release, perhaps finally showing that even they can succumb to market pressures to put date before quality and innovation.
We are all Script Kiddies now
The world moves at pace that I've heard referred to as "internet time" or "web time". Example: "Two years in web time is an eternity." Given that, can developers afford a classical style of learning? For that matter, are calls for educational reform just about class sizes and getting teachers more money, or are they also considering the way the internet is changing the way we learn and calling for a major paradigm shift in the way we teach?
Another report I've heard is that our youth today may seem superficially proficient with technology, but that while there are indeed some brilliant coders in their ranks, there are even more that are actually just comfortable "users" of technology, rather than masters of it. They can dig into menus and launch apps with the best of them and can seem, and are, supremely functional with their technology. They can text at lighting speeds, slap photos onto facebook in a heartbeat, and find a nearby restaurant on Google Maps, but they can't replicate the tech and most of them probably are as lost as their elders at configuring items in the deep recesses of the sub menus. It reminds me of the Issac Asimov story about the society in which everyone used calculators and only one person knew how to perform math by hand; he killed himself under the burden of the knowledge.
In the end, is becoming a script kiddie a turn to being a cheap, lazy programmer or is it just being an efficient one? Is it simply accepting that this is the way the world works and that you'd better adjust to compete? The truth is somewhere between the extremes, where it usually is. But I fear more people are turning to the script kiddie way and that it can lead to side effects, and a whole different kind of "dependency injection", that we're not preparing for.
Sunday, November 06, 2011
The Linux Adventure: Part 1 - Hardware
Ok, so I'm finally going to get more involved in using more operating systems and some languages on the side for learning purposes.
To help a friend out with some projects I've picked up an HP laptop, the DV6 6047cl and I'll be dual booting with Windows 7 64bit Home Premium and openSUSE 11.4. I'll catalog this adventure in a series of posts that will encompass a review of the laptop, the various steps taken to install Linux, and any roadblocks I encounter on the way.
Part 1 - Hardware
Picking the damn notebook was 75 percent of the battle. I went back and forth over several details and surveyed several units I found online and at retail outlets. Time was a bit of a constraint because my friend is already way ahead of me with the whole LAMP install and is already trucking along with his code.
The toughest parameters to agonize over were the laptop specs and price. I wanted a notebook with a big screen because I want something that's easy on the eyes and would look good if I needed to run videos or work with graphics. I expect to be hashing out a lot of php, perl, and MySQL code, so I wanted a good processor too.
For a while I was leaning toward a really high-end machine with all the goodies, but I just couldn't get it to the $1000 mark. Getting the big monitor, good video card, Intel i7 processor, backlit keyboard, Bluetooth, and HDMI support in one machine for that price was not possible in the places I looked. Even raising the price, it was still hard to find notebooks that put all that into one bundle for less than $1200.
I finally decided on the DV6 6047cl on sale at SAM's Club for $900 (originally $1000). Intel i7, 8GB RAM, switchable graphics between the Intel onboard video and an ATI Radeon HD 6770M, and 1TB hard drive. Also got the Bluetooth chip and HDMI port and some USB 3.0 ports, but missing a backlit keyboard (this is such a handy feature, why is it considered such a luxury item by both Dell and HP? You had to go very expensive to even get the option on the custom builds).
The 15.6 inch screen was disappointing after salivating over the 17.3 inch panels that the high-end Dell and HP units have at full HD (1900 x 1080). But after working with it a bit, the 1366 x 768 resolution isn't terrible (ok, it does seem a little squashed height-wise) and the images are crisp enough. I gave up on the 17.3 inch screens when I realized they wouldn't fit in the cases and backpacks that I use now. I don't expect to carry the notebook through a bunch of airports but I did want a reasonable amount of portability. At just under 5.8 pounds, it's not too bad for carrying.
Realistically, I probably could have been well satisfied with a much lesser machine. SAM's Club had an HP unit running the AMD A6 3400M chip whose integrated video capability is superior to the Intel onboard video...and it was $300 less. But when I looked at the CPU ratings on notebookcheck.com, I just saw how far below even the newer i3 chips the AMD was, and I decided for the i7. Maybe that was stupid, cause I don't plan to run a lot of games on this, but I had these visions of me doing MySQL backups and running compilers and just sitting around with my thumb up my ass and an hourglass on the screen and I just decided to buy the i7. Besides, I still would be using Windows, and that bloated thing will eat all the processor you give it.
The $900 wasn't a fun hit to take, but over a decade ago I bought a Dell Inspiron Pentium 233Mhz laptop for about $2300, so I just shut up and bought the damn thing. Was it worth it? Read on.
Hewlett Packard DV6 6047cl Review
I suspect SAM's dropped the price to flush out the notebooks that had been sitting in inventory for about six months, but I could be wrong about that. I made the purchase in August 2011, and since then, the SAM's I visit hasn't gotten any new stock but the prices went back to normal and haven't changed much. The notebooks they have there are just sitting around and don't seem to be moving...although it might hurt, SAM's has got to realize that tech generally doesn't hold its value well. Lots of even cheaper and newer notebooks at Best Buy are coming out with new circuitry that give them Bluetooth, 802.11 b/g/n, WiDi, and even WiMax support. This DV6 gets the former two but not the latter two; WiDi and WiMax are luxuries but would be great features to have if you travel and do presentations.
Physical composition
I can't lie here; most of the reviews of the DV6 series that I've read seem favorable but I disagree. For what would have been $1000 when it first came out, I'm a little disappointed in the build quality. Everything on the notebook is made from plastic. The lid feels flimsy and the unit falls way short of the Apple stuff; it's not as expensive, but at a grand, it is close enough in price to be better than it is. Disappointing, especially considering that comparably priced DV7 units, while also plastic, tended to look better. Guess HP had to cover Mark Hurd's golden parachute somehow. However, like most Wintel stuff it's serviceable and everything worked correctly out of the box.
In retrospect, I probably should have sprung for the larger monitor. I think the number one computer component to spend money on is probably the monitor: it's what you subject your eyes to for hours on end. The DV6's 15.6 inch screen is plenty crisp and clear but I think the higher resolution on the 17.3 inch screens would involve less scrolling and certainly some apps (games, photos) would look better.
That said, I'm appreciative of the DV6's relatively portable dimensions. It's not too heavy and it fit into my old notebook backpack.
The keyboard is a chicklet-style keyboard (I've also heard some refer to it as a "floating island" keyboard). I do like this keyboard a lot. Typing is fairly easy to do and I like that it includes a numeric keypad. The navigation keys aren't anywhere you recognize from your desktop keyboard, but such is life with most notebooks. One quirky thing is that the function keys appear to be set to control notebook functions by default and to make them trigger regular functions (for example, F1, F2,...etc), you have to hold down a "Fn" toggle key. Weird. I am used to the application software functions being the default slaving, and the notebook controls (brightness, music controls, volume) requiring a special function key. This might be configurable but I haven't delved through all of the DV6's documentation yet.
I must give a thumbs-down to the touchpad. It is from hell. In both Windows and Linux, its default setting must be called "annoy." It is painfully sensitive, causing the focus to jump to wherever the mouse cursor is when you are typing. I don't know how even the most patient human being could use this touchpad and not want to commit suicide within a couple hours; the most fundamental function in computing, to enter text via keyboard, is compromised. The only reason I haven't returned the notebook due to the touchpad is because I've progressively been able to improve its performance through configuration tweaking.
- In OpenSUSE, I was able to toggle off a "tap to click" option that has successfully stopped the touchpad from making the cursor jump everywhere.
- In Windows, I've yet to completely solve the problem but I've been able to reduce it somewhat by tinkering with the sensitivity settings. Although I disabled the same "tap to click" functionality I found on the OpenSUSE side, the Linux drivers seem to have handled this particular malady much better than Win 7.
Performance
The DV6 fares well here. Obviously the i7 2630 QM is a big factor, but the ATI 6770M helped too. The Windows 7 experience index scores 5.9, which is what a lot of quad-core PCs not using solid state drives will rate. All the individual categories outside of drive performance rate higher.
Windows 7 runs smoothly and so does openSUSE (I'm running the KDE Plasma UI). I really didn't notice many issues with the system stalling or waiting around a lot.
I haven't tried many games on it yet but the one I did was Civilization V. I was pleased here. Civ V really kicks my desktop's ass. While the desktop is not comparable to modern screamers, it's not too slouchy for a two-year-old PC: an HP with an AMD Phenom II X4 3.0Ghz CPU, 8GB RAM, and an nVidia 9800 GT. But Civ just kills it. The HP DV6 runs Civ V in a less demanding resolution, but it's significantly smoother even at high detail settings. So score a point for the notebook.
Battery Life
The DV6 uses the newer switchable graphics system. It comes with both an Intel integrated video chip and an ATI Radeon HD 6770M discrete graphics card. The notebook is supposed to be smart enough to know when to switch between the two automatically to preserve battery life.
So far, I've noticed that it seems to work ok in Windows 7. You can configure power profiles with the included "Configure Graphics" utility available at the context menu when secondary mouse-clicking on the desktop. Typically when the notebook is unplugged it will switch to using the Intel onboard chip, and when plugged in will use the ATI card. Preliminary tests show this to be the case, but I'm not impressed. I am getting about three to four hours of battery time when using the Intel graphics. Hardly what was advertised, but then I suppose there is a price to pay for the i7's strong performance.
Note: HP notebooks in the 61xx series (mostly DV7 but also some DV6 units) are said to have issues with the switchable graphics. It's possible my unit does also, as I haven't tested trying to run on the Intel chip and then see if running a game causes it to automatically switch to the discrete chip. HP is working on it, but apparently the fixes so far are reportedly less than optimal.
Battery life under Linux is a different story. I'm still tinkering with the setup, but it appears there isn't a definitive support stack for the switchable graphics system yet, and so both cards are powered at all times, draining the battery in less than two hours. More on this later in the Linux portions of the article series; it's not a high priority to fix at the moment but I would like to address it at some point.
Features
I'm pleased with the DV6's showing as an all purpose machine under both operating systems. Web browsing, office work, music, games, and video all seem to run great. The DV6 is quite versatile. The Blu Ray drive supports LightScribe and DVD burning, so you can do a lot with it, though it is understandably slower than my desktop's drive.
This is also one of the notebooks featuring "Beats Audio by Dr. Dre" whatever that is supposed to mean. I'm an old fart that associates names like Bose and Yamaha to the quality audio gear, and I don't know much about Dr. Dre (besides that he's a rapper) and HP's infatuation with him, but I will say the notebook sounds nice. Notebooks have tiny speakers, so they're not really supposed to sound all that great, but this one seems to do better than the average notebook. Actually, I'll say that I like the sound very much. The notebook seems to have multiple speaker ports: two in front and possibly another under a grille that stretches across the back of the notebook.
Conclusion
I'll keep the DV6. Parts of it were disappointing but the performance is good and so far dual booting is working out well. It's also a well-appointed notebook with good multimedia support and plenty of ports. The two USB 3 ports are nifty; I tried out copying an 8GB file from a friend's USB 3 portable hard drive and it took just over a minute which blows away the USB 2 performance.
Linux guys, please do not all attack me here, but I will say that while Linux has clearly come a long way in being install-friendly, so has the Microsoft OS. Win 7 wins the comparison in ease of use. I had no problems whatsoever getting drivers and hardware to work, and except for the touchpad, everything just plain worked without hassles. Linux is great, and I only gain more appreciation for it as I continue to work with it, but I had to fiddle with things a bit to get the WiFi and Bluetooth to work, and I'm not sure yet if USB 3 and the DV6's fingerprint reader work under Linux.
Sunday, June 26, 2011
Terms for the New IT Dictionary
I'm going to save this space to copyright a few terms I've come up with that have consistently amused my peers in IT. I'll add them as I find them.
Outlook Jockey
This is what I call project managers that only superficially perform their duties. They organize meetings and send emails. But they don't control scope, they don't understand the business or the users, they don't forge relationships with stakeholders and then carry forward and foster those relationships with the other parties on the project. They don't communicate regularly with everyone and then help break down barriers between developers and users. In short, they aren't doing much work at all except to look busy setting up and running meetings and emailing status reports. They're glorified messengers, getting a status from one party and passing it to the next.
No, I'm not talking about the top ten percent of you that do a great job. But the rest of you must qualify for the rating, because when I use the phrase "outlook jockey" I always get a reaction. People don't laugh at something because it's funny, they laugh because it's true.
Requirements Sentence
Forget about requirements documents.
If you're doing it right, you've moved on to more effective forms of requirements capture that span everything from use cases and graphics to wikis and co-locating developers and users.
If you're doing it like everyone else, then you're probably going off what I now call the "requirements sentence" because that's usually what you get: one sentence describing the system that's wanted. "I want a system that will do ERP and take care of everything from beginning to end and be fast and work just how I want and do leverage and acquisitions and stuff. No, I don't have time to help with requirements." Uh huh. Thanks, Mr. Big Picture Guy. Maybe you can get your buddy Mr. Vision Guy to help out between shopping for inspirational office wall posters.
To Earn More and Learn More
It's what you say when people ask why you are leaving a job. "Because I want to earn more and learn more." This one isn't a joke. When good employees leave, this is usually the real reason!
Subscribe to:
Posts (Atom)