IT 3.0
The three future jobs of the IT industry: Consultants, Project Managers, and Developers. Or, in the terms we’ve been using for years: Offense, not Defense. It’s always nice when the market provides proofs of concept!
- Use IT to strike, rather than parry
From ZDnet.com:
There’s a general anxiety that has settled over much of the IT profession in recent years. It’s a stark contrast to the situation just over a decade ago. At the end of the 1990s, IT pros were the belles of the ball. The IT labor shortage regularly made headlines and IT pros were able to command excellent salaries by getting training and certification, job hopping, and, in many cases, being the only qualified candidate for a key position in a thinly-stretched job market. At the time, IT was held up as one of the professions of the future, where more and more of the best jobs would be migrating as computer-automated processes replaced manual ones.
Unfortunately, that idea of the future has disappeared, or at least morphed into something much different.
Image via Wikipedia
Read Part 1 here.
THE BUTLER DID IT!
The RUTUS process can be further enhanced by searchable knowledge bases, search engines, and technical forum postings. Even if I have not seen this problem before, someone out there may have. The challenge of searching for the answer in the public domain is choosing the search string that is most likely to get a relevant hit without also dragging along thousands of irrelevant hits.
Finally, if I run out of my own usual suspects but know some really good consultants, I will give them a call or email and see if they have “seen this” in their experience. Most people do not want to take the time to solve a problem for me, but if I can show that I have done my homework and just need a missing tidbit, I generally get helpful responses.
There are several downsides to RUTUS. The first and most obvious is that it does not converge on a solution. Secondly, since it depends on the experiences of the consultant and factors somewhat out of their control, it does not always uncover even known solutions. Additionally, I have walked into many situations where the incumbents were suffering from “out of bullets” despair. They had “tried everything” and still the problem persisted. In this case, it is time to abandon RUTUS and move to something that converges.
Performance Tuning – Round Up The Usual Suspects, part 2
‘SCAPING GOATS
Part 2 of 3. Read part 1 here.
Time is of the essence, and it is useful to first eliminate the techniques that rarely work. Someone will have a success story about each of these, but they are a bomb with a lit fuse that I like to avoid.
Blame the hardware – The moment hardware is installed it begins to get old and slow. Pride of ownership does not last long, and IT people relish having new, faster systems at their fingertips. There are, of course, times where the hardware was underestimated for an application. Most applications run just fine with the 100 rows of test data, but when the real data starts to flow and the CPUs run red hot people are quick to blame insufficient hardware. “If only we had more, faster CPUs this would run just fine.” Though that is a testable hypothesis, it will come out of other methodologies if it is true.
One of the greatest inventions in computer technology is the loop. One of the greatest sources of performance problems is a loop within a loop. If each loop is working on a set with approximately “n” members, then the loop within a loop has an execution order of “n2” (n-squared). When “n” is our 100 rows of test data, “n2” is 10,000 executions. When it is a million rows, “n2” is now 1 trillion. That’s a lot of executions, even for a fast cpu! If you add a CPU that is 50% faster, and “n” continues to grow, the performance will continue to degrade. It is better to identify and re-engineer the million row loop-within-loop than to chase the problem with new hardware.
Blame the network – Generally when a network is slow, it is slow all of the time for everyone on it. Temporary network slowdowns can occur if someone is moving a large file on the network, or if there is a critical piece of hardware beginning to fail. These are easy to spot and alleviate. The tricky network problem occurs when many people collectively blame the network for performance degradation with no empirical data to support it. I had a user call the IT manager one day and complain of poor network performance. Since the IT manager was short-handed that day and I was consulting for something longer term, I offered to handle it. The user showed me the application he used and the screen that was slow. Noticing that the screen was painting data a few rows at a time, I called the DBA for the database I suspected the application was querying. “Have you lost any indexes lately?” I asked. “I don’t think so, but let me check.” She replied. “Ah, wait, we reorganized the table last night and the index did not get put back. I am adding it now.” We ran the application again after the index was put back and got sub-second response. My friendly user called across the room to his other compatriots “They got the network fixed. Go ahead and use it again.” In my experience, the network is an easy target for unsubstantiated blame.
Replacing network parts and installing new servers with the hope that a performance problem will be fixed are both follies of the shade tree mechanic. Perhaps you have had experience with the mechanic who begins replacing suspect parts under the hood until one eventually fixes the problem. This is an expensive and inelegant methodology that does not necessarily converge on a solution. If the problem is bad fuel, replacing parts will not find it. Similarly, as in my story above, replacing network parts would not have found a missing index. As a professional performance tuner, I seek first a methodology that converges on a solution, and secondly one that converges during my engagement time-frame.
Next post: The butler did it! Round Up the Usual Suspects, Part 3.
Performance Tuning – Round Up The Usual Suspects, part 1
Over many years as an application designer, builder, tester and tuner, I accumulated myriad experiences with performance tuning. During that time, I discovered there are methodologies that work, and ones that do not work. In some situations I was welcomed; in others I received a cold reception and on occasion a hostile attitude. My intent in this three part series is to give you the benefit of what I’ve learned, often one excruciating lesson at a time, in order to help facilitate your rise to a professional computer applications performance tuner.
EGO ERGO
The scene: The moment you arrive, be prepared to be under evaluation and scrutiny. If that gives you trouble, this is not a good role for you. The person who recommended you is concerned that your failure will reflect on them. The person who is paying for it fears that they are wasting their money on you. The technical people are worried that you will find something obvious and make them look bad.
The first challenge of tuning a system that you did not create is to deal gently with the egos of the people who have failed to solve the problem. Even if they appear to invite you with open arms, it is important to be supportive and to maintain a humble confidence. You need their help, and even though they need yours too, nothing sets the engagement off on a worse path than cockiness. Stay cool!
Though failure may cause ugly consequences, there is no guarantee that success will elevate you to the white horse. Manage expectations by sharing some of your credentials while praising previous efforts. Let people know that you are not necessarily smarter than they are, but you follow proven methodologies, learned from years of experience, that consistently converge on a solution.
Invite the people who have worked on the problem already to become part of your team. Remind them that you are only a temporary resource, and they stand to benefit mutually from a successful resolution. This is also when you introduce the concept of gaining familiarity with the nature of the application, and ask for some time and patience while you make an initial assessment.
During the start-up of a project I am often bombarded by superfluous input like “it worked fine until they installed the new …” and “we tried that” claims. Gently push back by asserting that your approach works best when it is followed without interruption. You are on a time-frame, and unsolicited input, while well intended, is more of a distraction than a help. I generally tell managers that a tuning effort will take X amount of time if I get full access to systems and technical people, and 2X if they insist on helping. There have been several experiences where the factor was closer to pi.
Next post: “‘SCAPING GOATS – why you should let them all go”
Now hiring: Technology Sourcing/Recruiti
Now hiring: Technology Sourcing/Recruiting Specialist http://ht.ly/2NaTt #SLGT @WeSLGT #houston #technology #jobs
Celebrating #42 on the Houston Business
Celebrating #42 on the Houston Business Journal’s Fast 100! http://ow.ly/i/44U4
Tune in to 650 AM KIKK today from 11 am
Tune in to 650 AM KIKK today from 11 am to noon to hear CEO Rick Jones discuss @BluwareInc and the Houston market. http://ht.ly/2GQiK #SLGT
Wishing you a safe and happy 4th of July
Wishing you a safe and happy 4th of July! http://ow.ly/i/2nJn
Check out Take Your Dog to Work Day over
Check out Take Your Dog to Work Day over at @HoustonDogBlog, http://ht.ly/23oOl... throw ‘em a bone and vote them Houston’s Best Blogger!
