Thursday, December 27, 2007

Google Reader and Contacts

The Google Reader group released a new feature recently that allows you the share the stuff you read about using Google reader with your Google g-mail contacts. Nice concept, but poorly thought out. It's a great feature, if all of the people you know on your contacts list have the same interests and hobbies as you. I think that additional tags should be placeable on your contacts, and on the articles that you find interesting. Multiple tags should be allowed to be placed on the articles, and your contacts.


I put together a simple 5 sphere chart of groups of people you would like to share stuff with. Not everything you find of interest , will interest other people. The more tags you place on a contact, the more you would share with them. Not a everyone gets everything option that now exist with the Google reader.

Seeing that Social networks is the newest rage out on the net, it still has a long way to go. This reminds me of the Seinfeld episode with the worlds collide. As Kramer says: That's gunna be trouble.

Friday, December 14, 2007

My Mini City

Someone posted a link in the forums for this site. Apparently you can create you own site, get your friends to click on a link and your city's population grows. Looks like a nice experiment for driving advertising dollars, and creating groups.

http://4rca.myminicity.com/

Post a note if you click through. It might be something fun to watch.

Thursday, December 13, 2007

Ruby, Postgres and Primary keys

Started working on one of my first ruby projects. The first issue I have run into deals with keys for a table. In my designs I had a primary key that I used. It was causing an error message when trying to create a record in the table.

User Create (0.000000) RuntimeError: ERRORC23502Mnull value in column "user_id" violates not-null constraintFexecMain.cL1818RExecConstraints: INSERT INTO users ("end_date", "last_login", "name", "salt", "start_date", "hashed_password", "last_session", "user_id") VALUES(NULL, NULL, 'user', NULL, NULL, NULL, NULL, NULL)

I couldn't find anything that would show me how to not include a field in the automatically generated SQL by ruby. I did notice after looking at my table that ruby had created it's own primary key for the table and that it isn't included in the auto generated SQL.

Solution roll back to a previous version of the database that didn't have my new user table remove the column definition in the db\migrate\002_create_user_table. Then migrate back up to the current version.

rake db:migrate VERSION=

I do intend to find out how to override values, if they can be overridden.

Labels:

Wednesday, December 12, 2007

W00t word of the year

This is a word that gets repeated over and over after Pawnage inside WWII online. After the last CP is capped and the ownership of the town changes, crys of W00t !!!! echo across the country side. Then the battle for the next begins.

Tuesday, December 11, 2007

Risks of outsourcing, knowledge retention

For the past 2 ½ years, I have had the privilege of working in an outsourced environment. The company employs a few developers who oversee on site developers and development being performed over seas. This model does have its advantages. We are able to ramp up development quickly as the demand on a project dictates. The cost of development and re-development of our Oracle Apps customizations is decreased. Actually the incremental costs are lowered or rise at a lower rate over time. This allows IT to be more responsive to business changes, and have more resources available to meet project demands.

Outsourcing has its limits and risks. The first thing to remember with outsourcing for Oracle Applications is that you are dealing with developers who will at most only have 1-2 years experience in coding and coding in the Apps environment. If you pay more you may get someone with 5+ year’s experience. These programmers may have access to internal resources on their side to assist them in meeting development requirements but will they utilize them? This lack of experience increases the need for your in house developers who are managing the projects and code base to be very knowledgeable of all of the processes and enforcing code standards. This makes your development group of people very valuable to the company, and leaves the company at risk of losing knowledge if you developer leaves the company.

Contracts rule the relationship between your company and the outsource company. After 2 years, I’m starting to see turnover with our onsite and off shore developers. Why? The number one reason is costs. Everyone likes their annual raises; they are semi written into the contracts. The issue is that the job market for an Oracle Apps developer usually raises the costs for a developer greater than what was written into a contract. This causes turnover. Older contracts lose their experienced developers to new contracts. Why? The new contracts can afford to pay the experienced developer more money. This leaves the older contract capped at a certain experience level 1-2 years on average.

What happens when you do not keep your in house developers who are managing your code base up to market on their salaries and benefits? Your developers tend to leave, usually not one at a time, but several in a span of weeks. If one developer is not happy about what he/she is making. Then there is a high chance that the rest are thinking the same. Especially after the first developer leaves and tells everyone what he/she will be making. If your company is like the companies that I’ve worked for, your custom processes are probably stored on a network drive somewhere. Most likely grouped by project, or some other sort of method that know one knows how or why, except maybe the people who have walked out the door. With your experience walking out the door, you’re out sourced solution starts to perform less efficiently. Development times lengthen without the proper guidance. Utilization of your existing code base decreases. IT’s relationship with the Business becomes strained because of delays in meeting business demands.

Remember outsourcing is a way for IT to become more responsive to the business’ needs and in meeting a business’ demand for services. Outsourcing is not necessarily a way to do more with less or save the company money. Outsourcing is a way to have development done on demand and not incur the extra overhead for keeping idle developers on standby until a project is ready for them to code. If this is kept in mind and your in house developers are viewed more as managers of your code based assets instead of replaceable overhead. Then you will have a successful out sourced experience. Otherwise you may end up with a solution that costs the same and has the same results as if everything had been sourced internally.

Labels:

Monday, December 10, 2007

The costs of not dedicating resources

I've recently finished a project that exemplifies the hidden costs organizations incur through the lack of dedication of resources, or assigning more projects than what the current level of resources can successfully handle.

Every company, large and small has projects that need to be done. Projects are anything that is outside of the normal day to day activities involved in running the company. Some projects are done as a one time, while others like software upgrades will be performed periodically over the life of the software, company or both.

The company that I currently work for is big, a billion plus in yearly revenues. This company also has the luxury of high margins and a double digit growth rate. This roughly translates as money is usually not an issue to not do a project, and things change to accommodate growth. Things do change except in how the company views its projects. A large portion of growth for this company is through acquisitions of smaller companies. At smaller companies most projects can be done by someone as part of their normal day to day activities. Outside of something that totally changes your business, or you get bought by another company, you will rarely dedicate someone full time to a project. Since a large portion of the people in place to make decisions came from smaller acquired companies, the decision making on dedicating people to projects tends to follow the route that a small company makes. This becomes an issue when the project is now 100 times bigger for a big company as opposed to when they worked at a smaller company.

The biggest item that affects a project that lacks dedication of resources is time. Any time line defined for a project that does not have dedicated resources, will slip and miss deadlines. This project took 2 years to complete, with the first year of work being the equivalent of a throw away of all costs incurred. The project with proper dedication of resources should have taken 90 to 180 days. Training people on the upgraded software was the biggest time consuming item.

Another major item is the perception of a project. People do not want to commit time to a project, where dedication by upper management is questioned. Why is it questioned? If management did not think it was important enough to dedicate resources, then the project must not be that important to the company. This project was considered very important to the company, but it still lacked dedication. This software prior to the upgrade was preventing 10 other major company initiatives from being implemented.

A Third major factor is the increased risk of failure as the time line of a project drags on. When this project started out, The IT side had 3-4 resources semi-dedicated and knowledgeable about the product. The business side had 1-2 people semi-dedicated and knowledgeable about the product. By the end I was the only dedicated IT person, and the business had 1 that was dedicated but whose knowledge only came about by doing the project. Net effect there was 80% turnover and we were really down to if I left, the project would probably have to be extended for another year.

To sum everything up, not dedicating resources cost you time. Time costs you money and resources. More money and resources may cost you the success of your project. Rinse and repeat this with your company enough times and it may cost your company's long term viability. In other words, higher project cost brings lower returns on investment (ROI). Lower ROI, bring lower profitability. Lower profitability leaves less money to re-invest into the company.