Technology
General Technology
Read it here http://codeverity.com/blogs/tim_weaver/archive/2005/06/15/21.aspx
Or just read below for the summary
YahooSearch rules
....
Google and MSN get a big goose egg
I've begun a new series of posts on creating an HttpModule directed towards stopping unwanted comment spam.
Initial Post: http://codeverity.com/blogs/tim_weaver/archive/2005/06/13/5.aspx
Design: http://codeverity.com/blogs/tim_weaver/archive/2005/06/13/6.aspx
I've decided I can't wait any longer on the spam fix. DNJ has been great and I'll probably continue to direct posts from here to my new blog for the near future.
I've setup Community Server RC3 and have begun posting on the new site. It's likely to be a little iffy until I can iron out any issues that might come up.
Check it out here:
CodeVerity
RSS
I just got my weekly issue of (fill in your weekly computer rag) and under the news section is “Difficult ERP Rollout Slows Furniture Maker”. Is it just me or does this seem like the norm with SAP R/3 rollouts?
Let's see there was
The City of San Antonio
Rowe Furniture
Dell Computer
That whole UK fiasco with EDS ( I pretty sure that was SAP R/3 )
So my question is who is buying this crap and why do companies continue to try and roll it out when there is one high profile, expensive, failure after another?
Dell Computer tried to use SAP to replace its DOMs (Dell Order Management System). This was many years ago and the price tag that I recall was around 14 million dollars. For what? Not a single Dell employee was using SAP when I worked there. In fact Dell tried to replace DOMs so many times it became something of a joke [but that's another post]. It is always amusing to watch a company squirm because their entire backend system is running on a competitors hardware (Tandem).
Has anyone worked on a SAP R/3 rollout that wasn't a death march? I really want to know. Five or six years ago I was seriously considering jumping to the SAP platform because the developers were making gobs of money. These days you couldn't pay me to work on a SAP rollout. I'm both older and smarter. Who wants to work on something doomed to fail?
The big news in my life is that my tenure at Monster will soon end. It's been a great couple of years and I've really enjoyed myself. I wish everyone at Monster the best of luck in the future.
In the mean time I'll soon be starting at Compuware as part of the DevPartner Security Checker team. Got issues with the Security Checker? Let's hear them. I can't promise I'll respond, but I will make sure the team hears your concerns.
This is one cool smart client application. http://worldwind.arc.nasa.gov/.
I'm tired of all you tech-edians with your exclusive 'I'll be there' images and your blogger club. Well no more. Now all of us who can't participate no longer have to suffer the humiliation of not having an 'I'll be there' image.
The whole Software Engineer vs. Software Developer debate fascinates me. A lot of the arguments I hear/read seem to focus on the maturity of software development. The main argument being that software development is/isn't mature.
My father worked as a Chemical Engineer for Dow Chemical for 26+ years. To me he is an engineer. If I went to him and ask can you tell me how to convert raw crude oil to low grade automotive gas he could come back with a formula that would do it:
g = crude/(inputA * inputB) * heat 175 degrees (an example only)
In reality of course it isn't that simple, but it would be a formula. Now If I ask 'is that the only way to do it?' His response would be that yes, otherwise the formula wouldn't work. Now you could create a new formula, but the industry has adopted this one because it is the most efficient/least risky/etc.
Now take that question to a software developer. One of the first things the developer is going to want to know is where is he going to get the data? Is it coming from a DB, an end user, what? What types of object(s) are going to represent the data? Will I have to convert it from/to something? To the Chemical Engineer these questions don't matter. He has an abstract problem and has given an abstract solution. To a developer it is a concrete problem. He must know where the data comes from, what form it will take.
To me the two engineers are operating in completely different spaces. The software engineer rarely deals in the abstract yet the chemical engineer can do it fairly easily.
So what does that say about maturity? Well, not much really, but lets explore it a little further. To the chemical engineer this formula represents how you do this process. The industry has adopted it because failure to do so can have dire consequences (safety, revenue). The software engineer might not want to adopt the "standard". Maybe he is in a commodity market so cost is about as low as it will go. Now if he can speed up the algorithm by 20% with a 5% failure rate that may within his tolerance. No one is going to get killed and if the results are outside of tolerance he can always recalculate. It is a win. You simply can't do that with real physical product.
Now what about the software factories approach? To me software factories represent the mature sort of model. The developer is told we need to make crude oil. Go get the crude oil algorithm and then put a really fancy UI on it so that we can differentiate ourselves. The point is that the developer is using a known and predefined set of code. Instead of worrying about rebuilding the algorithm he is creating a better product/UI.
By that definition I would say that software development is mature; after all there are reams and reams of code already written and available that solve almost all everyday common problems, but that code is rarely used. The problem is that we work with numbers/code not physical items. The constraints that drove adoption of a single approach in the physical engineering sciences don't necessarily mean as much in software. As long as companies believe they can drive value out of customization/optimization of well known problems I don't see how we will ever get to the factories approach. That's too bad, because I think it has a lot of merit.
Why not? Here's mine:
So how do trees and software development relate? An example will help explain:
You just bought a nice house in a new neighborhood. In typical eco-friendly fashion the builder knocked down anything and everything that was alive before building your new home. Now you have zero shade in your yard and you would really like to have something aesthetically nice to look at – besides your half dead sod.
You decide you would like to buy a tree. You go to the “tree farm” and see that there are some really nice big trees. The guy selling them tells you that the larger the tree the more likely it won’t survive the transfer. For some reason the smaller trees handle the shock of being moved better.
After looking at the prices you conclude that you can only afford a small 2 inch tree. It looks okay at the farm and the guy selling it assures you it will grow fast. You pay to have it brought home. A couple of guys show up with a backhoe and dig a really big hole. The tree arrives and they put it into the hole and cover the roots. Once they are gone you quickly realize that the grand tree you envisioned (and the desired shade) are no where to be found. The tree looks a little pathetic. It is really nothing more than a twig sticking out of the ground. There aren’t even any leaves yet.
So your choices are:
a) Nurture the tree – it will grow slowly and over time it will become a grand old oak of the yard giving you exactly what you wanted
b) Go back to the farm and get a bigger tree – pay a lot of money, dig a bigger hole, and hope that the tree survives
So how is this like software?
Software development should follow the first model. It should be about small controlled projects that slowly grow over time in a controlled and planned way. If you start out with a huge project: you pay a lot of money, you have to dig a really big hole, and there is no guarantee the project will survive. The more controlled and smaller projects may not delivery everything you wanted/expected, but they won’t die on you either. They can be nurtured into meeting your expectations vs. having to completely replace it if it doesn’t.
So say you have this small tree in the ground and a few weeks go by. You figure out that you really wanted an Oak tree but you got a Birch. Now the Birch tree gives you some of the things you desired: shade, aesthetics, but it doesn’t provide everything: size, lifespan. So you go back to the tree farm and order the correct tree. The guys come out and dig up the Birch and haul it away. Now you are starting over with a new tree. It will probably survive, but it may not. It isn’t as large as the Birch, but it will get there.
In software the same thing happens all the time. Companies realize they have an application that doesn’t meet their needs. It has some of the things they want, but not in the way they want. So they toss it and build an application that meets their current needs/wants. Unfortunately those needs and wants change almost before the new tree is in the ground and they have to do it all over again.
If software project teams spent a little more time planning up front; looking at the current needs and possible future needs, then the projects can be structured in a way to more easily reuse some of its pieces. Of course planning isn’t enough. You have to have the vision to grow your “tree”. You have to use the right technology to enable that and you have to support the additional efforts it takes to get you there. Is the added cost of a few dollars today vs. the cost of completely replacing something really that much?
Go plant a tree and make it grow. Stop chopping down all my shade!
I’ve been reading Rapid Development. I must say that my initial reaction to the first few chapters is basically depression. One of the chapters focuses on “Classic Mistakes”.
I’m depressed because a) I’ve experienced almost each and every one of the classics and b) because I don’t see anything that is preventing them from happening again.
I thought I would post my version of some of the classics. So here goes mistake number 1.
One of the classics: Not getting rid of problem people early
I had this one twice in the same project (sigh). Basically we had an individual assigned to do a core piece of work on a project. I wasn’t the tech lead, but I was the senior developer on the team so I took it upon myself to keep track of what was going on. This dev decided he knew the right way to tackle the problem. When a few of use got together to discuss his design it became clear that his vision wouldn’t work and we told him why. He ignored us and continued. I took it to the tech lead, who worked for the same contracting company that the dev did (and was his friend). He spoke to him and still the dev insisted he was right and was allowed to continue.
At this point I decided I had enough. I’m not very good at keeping out of something when I see it is really screwed up. Myself and the other senior dev split the work between us and developed the solution on the side. When we were done (with both our assigned work and this other dev’s work) we went to the tech lead and explained what we had done. We showed the finished product. He thought about it and acknowledged that we were probably right. He pulled the other dev into the meeting and asked him to show his efforts. His code wasn’t complete and he still had a lot of work to finish. The tech lead decided that we would go with our code and toss the code that this other developer just spent 2+ months working on. The dev was pissed because he was kept in the dark. I was pissed because I had told them this was a problem at the get go and nothing was done. This dev had good skills and would have been useful working on something productive instead of just spinning his wheels.
As it happens this project had yet another contractor that was added a few weeks into the schedule. He was from a different contracting company. He was assigned a relatively minor piece of functionality. It was critical to the entire app, but minor in that it was just two pages and the supporting code. After a few weeks of coding he asked me to look at something. When I looked I noticed that he hadn’t gotten very far and that all his code used inline SQL. I explained that he must use stored procedures. He nodded and said something along the lines of I’ll get to that once it works. Later in the conversation it because clear that he had little understanding of ADO and didn’t know how to call stored procedures. I dug in a little more and decided that this guy simply didn’t have the skills necessary to complete the project. Once more I went to the tech lead and made my case. He agreed it was a problem and spoke to the developer.
Weeks went by and I continued to watch what this dev was doing. I already had my work plus half of another’s on my plate so there was no way I could do more. The dev still hadn’t finished the pages, let alone got the inline SQL out. I again went to the tech lead. He once more talked to the dev. He finally concurred with me that the guy had to go. He asked to have him removed and management refused. A week before QA I demoed the product to the business. It came out that their vision of how pricing was supposed to work didn’t match what they really wanted—big surprise. The project was pushed 3 weeks so I could rewrite the pricing engine to meet their new rules. The ADO dev was removed and his work was given to another developer (who just happened to be the one who we took work away from before).
So in one project I had two cases of developers who cost the company a lot of money because the individuals managing the projects couldn’t or wouldn’t remove individual even though they were obviously causing problems.
This is so sad it is almost funny. I've been exclusively using Firefox for a while now, including adding my posts to DNJ. Yesterday I read on someones blog over on CodeBetter.com that they use DNJ editor to post because the formatting tools were good enough. I thought... hmmmm. I don't see any formatting tools.
Then I thought... oh crap Firefox just bit me again. Sure enough when I opened IE there were the formatting tools. Maybe my blog posts will be more colorful now.
My day begins like this
Wake up --- okay this one is easy
Check gmail for feedback from my blog
Determine what my needs are for the day:
Do I feel like Texas Hold'em, Blackjack, or some other random game of chance
Maybe a little sex would be better? I'll take the viagra on post 3 and some of those prescription things on post 12
On bad days I just take everything -- you never know what you might need.
Final step
Delete all unnecessary posts usually accompanied by a large sigh
My previous post(s) here and here I vented a litttle about the new spaces.msn.com site.
Mike Torres was kind enough to respond to my last post with a clarification and notice that they were looking into alternatives. Its nice to know that the spaces team is actively listening to the community. I think I would be remise in not pointing out a few more things about the new spaces site
I setup a blog there and am actively using it
I have recommended it to friends and family
I've yet to experience an error using the site
The very same people who complained about not being able to comment also said "cool. I should get one of those"
I really like the ability to do slide shows with pictures (though a few more meg would be nice) and I really like how customizable the entire site is, though if you bothered to look you would notice I haven't actually done much to mine... yet. I won't do a "review" of spaces because a lot of other people have already done that (better than I could no doubt). There are a lot of blogs out there these days and lot of them are free for the taking. MS has created a blog with a lot of value add. Whether or not the public will latch on to that I can't say, but a few complaints aside I must say I'm impressed with what was done, especially given the timeframes involved. The spaces team obviously did a lot of work to get this thing out the door and it could have been a real black eye had it been riddled with bugs or just been completely unusable. I find it to be neither and will continue to use it. It will only get better with future enhancements.
I recently added a blog for family related stuff on spaces.msn.com. I tried to add an entry this morning and typed:
msn.spaces.com. I didn't get what I expected
It doesn't bring up the new blogs it brings you to a page that isn't even identifiable as related to msn.com/spaces. I'm wondering about the MS thought process here. The URLs are too similar. Why didn't MS pick a more distinct URL or at least get the msn.spaces.com url and put content on msn.spaces.com to allow you to find what you were looking for? This seems like a fairly obvious hole and a rather consumer unfriendly one at that.
I gave into a long running desire to have a Tivo about six months ago. I tend to avoid anything that requires me to pay a monthly fee and the one time fee seems rather large considering it is only good for the hardware, not the customer. I liked my Tivo. It had a few annoying things, but it became part of our entertainment center. The VCR that was never used was moved upstairs. The additional remote and the three to four buttons that had to be pushed (including one by walking -- gasp -- to the AV unit) were a tad annoying, but it seemed mostly worth it.
When I read about Tivo starting to insert ads into the skip feature I decided it was time to look once more at MCE. I had looked at it last year, but never tried it out. I decided my aging game machine could become an MCE. So I paved the OS and got MCE running. I ordered two PVR 150MCE and an MCE remote. Once I had it up and running I moved the whole thing down to the TV and hooked it up (while the wife was out). She came home and was more than a litttle shocked. My wife works with technology, but "hates" it. She hates learning anything new and she had just learned the Tivo, now here was something new. In order for it to pass the spouse test it had to be compelling. I thought it was. For one thing I was able to condense all the remotes down to one. No more physically having to touch the AV unit for volumn or to turn off the sound. The picture quality was excellent.
A few days past and the spouse was telling everyone how great MCE was. Then it happened.... The system crashed during a show. Wife was not amused to see the MS Windows XP screen. I had a few other crashes while burning CD's, but she wasn't aware of those. Well one crash led to another and pretty soon we arrived at "this thing has one week and then the Tivo is coming back". Now she tells everyone how it is a piece of crap and is always crashing. I find this very amusing. For one thing it isn't always crashing, but it was annoying. The shift from great to piece was what caught my attention. You see from a marketing point of view my wife is an ideal sounding board. The MCE originally was well beyond her expectations and she loved it. However it then introduced a problem she hated and now she feels the whole product sucks. Never mind that she can watched shows that were recorded while running on the treadmill in the basement, which you certainly can't do with a single Tivo; nevermind the fact that all the music and pictures are always there available. The product simply sucks.
When I setup the machine I moved it into the entertainment center. It was in a small cabinet that was also filled with VCR tapes. I noticed it was getting fairly warm in there. So I removed part of the back of the entertainment center and moved some of the tapes out. It still got warm, but not nearly as much. I was speaking with someone about my random crashes and he suggested it may be heat related. I installed speedfan and checked. Sure enough the CPU was running really hot--62C. I removed the rest of the crap from the cabinet and tore off the rest of the backing so air could more around more. I then added a small fan. Now the CPU runnings at 56C and I haven't had a crash for three days.
At this point you think the wife would be happy. However, she isn't. She still calls it a piece of crap. The fact that it was overheating and crashing because of how we (er I) set it up doesn't matter. All that matters is that it didn't work as expected and she isn't happy. It won't be going away because it is so much better than the Tivo and the crash problem has been solved. It will take a long time for the wife to come back around to "it's great". Lesson for all you marketing types (as if you didn't already know this). Your consumers can be your worst enemy.
Here are my 5 laws of prototypes that I've found to be universally true:
1) The answer to any prototype / feasibility question is always yes.
Okay I stole this one from Facts and Fallacies of Software Engineering - Robert Glass. In my experience this is always correct.
The problem is really one of what question is being answered. Prototypes tend to answer 'can we do this' and the answer is always yes.
However, the real question that should be addressed is something more like 'given the cost to do this, should we do it?'
The difference might be subtle, but if you apply it you are going to save a lot of money.
2) Whatever poor coding practices you use to build your prototype will be replicated in the final production version.
Developers tend to be lazy. It is easier to solve a problem by looking at how someone else did it and tweaking it if necessary than it is to start from scratch.
3) No matter how poor the performance of the prototype the production version will be much worse.
See #2. Bad coding practices almost always result in poor performance and lots of bad coding practices results in really bad performance.
4) Once in production a prototype will never die.
There is a perfect example here. This prototype was suppose to be pulled down in January 2003.
It's still going strong. It is very hard to justify taking away functionality from customers even if it is only a few and the functionality is limited, so it just doesn't happen.
5) Any controls used to build the prototype will be used in the production version even if they aren't appropriate.
See #2. Lesson here is when you build a prototype don't use the easiest control just to get it done.
You are going to have to live with that control for a long time so choose the control carefully.
Got any more good ones to add to the list?