Deadlines rarely align with the amount of time needed to complete work, and so technical compromises are made along the way. There’s a short-term tradeoff to get something working initially. The developer knows the lifetime of the solution and accepts that he or she will have to go back and create the longer-term solution later on. While those looking in from the outside might consider this to be sloppy engineering, it’s actually what allows products to be released on time. And also how tech debt accumulates.
A post on the BCS Project Eye blog back in November 2009, which picked up on the failure of the government’s C-Nomis project, sparked a lively debate among blog readers as to why so many big IT projects fail. Suggestions ranged from failure to monitor progress, to lack of accountability and ownership to arbitrary political pressure. However, one recurring message seemed to be that IT projects fail because of inexperience or simple incompetence.
Not even good work can crawl from wreckage. If a fine portfolio, a delightful career, and the satisfaction of earning your bread by providing a genuine service are to be had, you must first learn to manage your clients and colleagues.
Because it’s possible you may want to attend all sessions, Waterfall 2006 features no concurrent sessions. All sessions are run sequentially for your enjoyment. However, since in a waterfall process we don’t want testers to know anything about coding, or programmers to know anything about design, and so on, you can only attend sessions that match your job function. When you register to attend you’ll be asked to select an appropriate job function. When sessions that are not relevant to you are running you will be required to sit idle in the lobby.