Posted to tcl by colin at Tue Dec 08 01:31:27 GMT 2009view raw

  1. Todd, Alan,
  2.  
  3. I believe in speaking frankly, as a means to solve problems, so here it is: Teams work to cover weakness, teams then work to remove it. In that spirit, I offer the following.
  4.  
  5. Todd McDonell wrote:
  6. > Gday Colin,
  7. >
  8. > I and I'm sure many others appreciate your efforts, it will all be over in less than 8 weeks.
  9. >
  10. > There are many volunteers working on this project, some have been doing so for more than two years and everyone brings their own particular skills and volunteer time to the table.
  11. >
  12.  
  13. I appreciate your thanks, and understand that we're all under pressure. However: if it were possible, I would be thanked for having done useful and productive things, rather than for filling in for the incompetence of others.
  14.  
  15. We are trying to compress a year's work (maybe two years' work) into a couple of months. We're a few weeks out, we have some real, hard to solve, problems:
  16.  
  17. 1) I'm now having to scrabble for NEC phone information when I asked for access to this a couple of months back, and would have had it sorted by now. (This isn't the most important, and it's under control, but it's a symptom of our malaise.)
  18.  
  19. 2) We have no WLC, and no time to configure APs in stand-alone mode. We don't know if we're getting a WLC.
  20.  
  21. 3) There's no surge protection upstream of the UPSs, although they are operating in a lightning field.
  22.  
  23. 4) Telstra have given us an unbelievably misconfigured interface, we're a few days from their freeze. We can't even work out what's going on (we don't have the login to see what's going on.)
  24.  
  25. 5) Radius ... when will we have to step in and set that up for IT/Admin? What kind of battles will that entail? What happens when IT/Admin pull out their gear after Jamboree?
  26.  
  27. 6) Hardware firewalls DOA, necessitating intervention by servers which are only there because we had the foresight to insist on them 'for network monitoring.'
  28.  
  29. ... among others.
  30.  
  31. At every step of the process, we have demonstrated the foresight to avoid problems, or mitigate them, but at every stage it's a struggle. It shouldn't be a struggle. I feel like some kind of Cassandra, every time. I shouldn't. This isn't an ego thing, this is an "Because I am a pro, I know what is needed" thing. And in truth most of the pro-ness is Alan's, not mine.
  32.  
  33. > The thing I find most heartening is that Cooper and Brett have been helping us even though they are not members of the association and haven't necessarily signed up to the ideals of scouting.
  34. >
  35. > In this particular case, in your role as the barcode system manager, you need Luke to get the servers going with SQL before Stephen Smart can load the database.
  36. >
  37.  
  38. Quite so. And I refer you to my email of 19/08/09 21:38 (three months ago) to Stephen Smart:
  39.  
  40. | Steve,
  41. |
  42. | I've had a look at the barcode platform's specs, am lining up tools, and thinking about the app.
  43. | Any ideas or questions you have, I'm interested to hear.
  44. |
  45. | Meanwhile: What kind of database are you using, to which I'll be interfacing? That should tell me what APIs
  46. | I can use (or need to find/develop.)
  47. |
  48. | Colin.
  49.  
  50. I refer you particularly to the question about the database, the interfacing, and the APIs I needed. Had I been treated as an interface to their team, I'd have ensured that this requirement for installing the DB would have been covered. Instead, we're doing it the hard, slow, expensive and dumb way.
  51.  
  52. This is a recurring theme, with 8 weeks to go: I asked for information, resources, access, etc, in a perfectly timely manner. The request is either ignored, or as in this case I was railed at (by Sharon) for interposing myself in processes which putatively don't concern me. Surely Sharon worked out that the DB needed to be filled, and made provision and fallback provision for filling it? No? She must have known that she'd need external access by a given date, and informed us of it in a timely manner? No? So now it comes down to us hacking together something instead of Luke getting in a car and doing it on-site. We're filling in for Sharon's manifest incompetence.
  53.  
  54. Time passes, time pressure mounts, and instead of being consulted and listened to, allowing us to solbe the problems when it's easy, and in a manner conducive to good practice and timely execution, we are landed with a significant problem on the critical path, it becomes our responsibility, and those unable to foresee the issues are *still* setting the agenda.
  55.  
  56. This isn't resemble teamwork, this strongly resembles servitude. The admin/IT people have been treating us like work-for-the-dole volunteers.
  57.  
  58. And: I'd swallow that level of disrespect if it lead to a successful outcome, would do it for the sake of the team and the project, but it is demonstrably a failing strategy. So it is for the good of the team and the project, and in the course of exercising due skill and care, I have to say that this 1980s-style management idiocy has to stop.
  59.  
  60. > As I expect to have sim cards and the remaining 38 scanning guns this week we want the database going as soon as possible so that we can test.
  61. >
  62.  
  63. Sure, and I'll set up a tunnel, or Coop will (to avoid hammering my linode's bandwidth.) But I want it clearly understood that this is one of the least efficient methods possible for achieving the stated goal, that it has been undertaken in ignorance by the IT people, that a scintilla of foresight or taking advice might have saved us unnecessary effort, expense and pressure.
  64.  
  65. Colin.
  66.  
  67. > So thanks for helping Luke to get to the servers, in a very real way it helps our cause as well.
  68. >
  69. > Cheers,
  70. >
  71. > Todd
  72. >