Gary works in a huge conglomerate. There are about 500 developers and assorted low level managers on his floor alone, and everyone is constantly on live audio-chat with their remote peers. As such, you can pretty much hear all of the conversations going on at any given time - if you listen... (see if you can guess whether the engineers or managers are in italics)

"We need to put foreign keys on auxiliary tables in order to enforce the relationships between primary and secondary data." We don't need foreign keys in the database; they slow everything down and make it harder to delete stuff. We'll just keep everything straight in code!

"We need to get requirements on when to do rounding, and what type of rounding to do." What do you mean? "Should we do rounding after each mathematical operation, or after every logical computation? Should we do it on a record by record basis, on an aggregate basis or something else? Should we round up, down, half up, half down, half even? To how many digits of precision? Should all the different computations use the same rounding rules or are they different in each case? The requirements say nothing about it!" We can decide that after the application is finished; we'll see what the data looks like and decide if things need to change.

"We should set up database roles, assign permissions to each role and assign relevant roles to appropriate groups of users. This will make things much easier to manage." It's much simpler to just assign all the permissions each person needs to them individually. "No it's not. We have about 200 tables, each of which needs table-create, drop, insert, update, delete and select privileges. That goes with about 200 sequences which need create, drop and use privileges. Then there are the stored procedures, functions, triggers and views. Multiply all of that by 10 developers and 35 users, and it becomes quite unmanageable." Maybe, but we don't have time to invest in this; change privileges as needs arise!

"Per project plan, we have written > 1,350 JUnit and JBehave (business driven development) tests and scripts to verify the code in the main processing module. Everything works per the tests, but the tests were designed to verify that it works the way we intended. The users haven't yet specified the primary functionality of the core of the application. If they fill in the requirements with anything other than what you told us to expect, most of this stuff will likely need to be changed. We should stop writing tests until the users provide final requirements!" No, keep writing tests. If we have enough of them and it becomes too cumbersome to change it all, the users won't be able to make changes to this iteration of development, and it will all get pushed to version 2.0!

"When you made the project plan, you assumed that nobody would be doing any code changes to the legacy system. Further, you assumed that only one person would be doing 50% production support and the rest of us were 100% dedicated to development. In practice, we've all been doing about 30% production support plus functionality changes to the legacy system. This is going to translate directly to missed deadlines. Before you accept any more requests from the users, you need to tell them that the cost for the request-of-the-day is a delay of <time> in delivering the new project. Then agree to do the work only if they agree - in writing - to the delay." No, I am not going to say 'no' to the users. They are our customers and they get what they want! "Nobody said to say 'no'; just that they must agree to the cost of doing the work, which translates into delays on the new project." I don't care, we'll all just put in extra hours to make up for it. "Wait; 3/4 of the team is hourly consultants who are contractually limited to 40 hours per week. They're not going to work for free, so they won't be putting in any extra time. There's no way you'll be able to deliver this thing on time; you're digging a very deep hole with no escape clause!" Just keep doing the work on the legacy system!

"You can't just hire junior developers with 2-3 years of experience." Maybe, but we can hire two of them for less than what we pay an experienced engineer. "That may be true, but the experienced engineer will generally out-produce them by way more than 2:1. In the long run, having a couple of more experienced folks is cheaper than fixing the damage caused by very inexperienced folks." Productivity doesn't have a line-item on the budget. I get reviewed on (among other things) by how well I work within my budget!

Gary now keeps his head down and makes a concerted effort not to listen; however, he's developing his own escape clause for when the time comes.

[Advertisement] BuildMaster allows you to create a self-service release management platform that allows different teams to manage their applications. Explore how!