Monthly Archives: September 2012

Thomsett on Outsourcing

Outsourcing: The Great Debate

Notable points and some that remind me of my own experiences:

  • the difference between process and project work, and how most other industries outsource the former – but in IT the latter is often outsourced
  • “squeaky wheel syndrome” – outsourced functions’s success may be improved by the increased attention given to them by the outsourcer’s management simply due to the cost/contracts involved
  • outsourcing organisations typically track work much more accurate than internal departments (who often have “hidden” work), so it’s difficult to compare and measure success
  • arrangements sometimes start with the outsourcing organisation’s top staff working on the project, but over time these are replaced by lower-skilled staff
  • loss of intellectual capacity – if the outsourcing involves transfer of staff, the best staff are the ones most likely to leave for other companies, leaving an averaged-down group
  • the outsourcing organisation’s lawyers are likely better/more experienced in the area than the outsourcer’s
  • potential loss of intellectual capital (see IBM-Microsoft)
Advertisements

Schauderhaft by Jens Schauder

I recently discovered the blog of Jens Schauder thanks to a colleague, and wanted to note links to some of the posts I found interesting.

Boolean Stack – an idea of simplifying complex boolean rules by expressing them instead via collections of “allowing rules” and “denying rules”.

Developing for Supportability – exactly what it says, including how important it is to make it easy to stop and start your application.

8 Reasons why the Estimates are too low – the top 2 of those I have experienced are: having estimates prepared by developers familiar with the area of the system, and then expecting completely new developers to take the same amount of time; and estimates having to be made with nowhere near enough information available.

Another extra one I have seen is the assumption that all developers will spend 80-100% of their time on their tasks, which doesn’t allow enough time for meetings, design and code review sessions, etc. Starting at 80% would be fine if there was some effort to monitor whether this was realistic and then adjust it if necessary.

One Database for Every Developer – enough said. It’s not as bad if your application only reads from the database, but it’s still a pain at times.

About Packages – how packages aren’t always used effectively. As mentioned in the comments, I also see packages too often used as sorting containers e.g. “exceptions”. I think if we paid more attention to this, we’d also put more thought into the visibility modifier of our classes instead of just making them all public.

Breaking Dependency Cycles – what it says it is.

Fixing the Singleton – why singletons should only be used via dependency injection.