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)
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.
I just finished reading this book. I highly recommend it.