There is not one thing called a software development department. Or the "Programming Division of IS." Or whatever it is called at your company. Each department is very different whether it employs 3 programmers, or 30, or 3,000. It's different yet again whether you help sell books for an e-commerce site, make garage doors or thermostats work, help create a program that gets burned onto CDs and shrink-wrapped and sold in Wal-Marts throughout the world, or make, automate, and integrate business applications for a government entity. But in each of these very different places seethes a very real and very scary possibility ”the possibility that your team is slowly bled for resources (people, money, tools, access, and so on). We have all felt it. That's bad for us, and we have all talked it to death because it's a drag. What we don't talk about as much is what happens to the organization when it starves us like that. What happens should be no surprise. The same thing happens in the world when people are starved of resources, money, tools, and access to things they need. Think about books that have been banned. Or the prohibition on alcohol in the 1920s. Or drugs of all kinds. These things don't cease to circulate because they've been outlawed. They still thrive. But they thrive in a black market. Which is a very dangerous place. Maybe you've never experienced this developer's black market. Maybe the reason that you've stayed at your same company for 10 years (ha) is that they lavish you with time, money, resources, tools, people, and access. But I rather doubt it. A black market is where people illicitly acquire and distribute goods and services. Do you work in a developer's black market? Ask yourself the following. Have you ever run down the hall to the offices of your friends down in networking and asked for write permissions on a directory somewhere on the network? You just need this quick fix, just this once, then your app will work and you can all go to lunch , you tell her. You explain that there is not a security policy in place but this would do the trick and your manager is on a conference call and you can't move forward until that directory is available for your app to write to. This workplace has a black market. If you call someone in your organization that works in a related department and get him to do a favor for you to help make your application work, you have a black market. Your organization's software is dependent on the personal good will that its workers generate toward others, or, if you are not an optimist, how easy it is for you to manipulate or coerce your coworkers. You shouldn't have to cut deals to get a project done. If you have to cut deals to get your project done, it is because your organization is asking for something that they can't afford or don't want to pay for. In my view, you're going to either pay now, or pay later. And when you pay later, the cost is always, without fail, far, far more. This is true for testing and commenting and debugging too. If a company lets its departments run on the black market, it is going to pay later. If your department's product depends on a black market, you must help stop it immediately. Determine what you need to get your job done. Not what they want to hear. What you really need. The real hours. The real cost of 14 copies of that IDE. The real number of programmers. These things we are used to asking for. We do this a lot. It's easy to put them into MS Project and everyone can print it out and think they have a plan. Typically, this is the culprit right here. Just like no one in their right minds would think that a significant set of ideas can be satisfactorily represented in a whiz-bang PowerPoint presentation, don't think for a second that the fundamental coherence of a plan can be represented in MS Project. I am not bashing Microsoft here. Those applications are great for what they do. I am saying that they don't do what we hope they would: they don't give us a plan anymore than Word writes the great American novel simply because it has a (flawed) grammar checker and lets you type. Do not mindlessly assent to working on incoherent projects. You will become miserable. Ultimately you will quit and try to sell your family on how exciting Fresno really can be since they have a new programmer position waiting for you there. Impress upon your managers the importance, the necessity, of a long- term , coherent plan. Do not make one-off apps in the dark. Consider long-term architecture. Make modular applications that allow you to maximize the re-use of code. This kind of thing takes planning, yes. But it also takes knowledge of what you're going to do next , so that you can see what you might want to re-use. Ensure that changes or architecture you want to introduce will have a visible, positive impact on customers. If it doesn't help your customers, you have a very hard case to make. Yes, business changes. Yes, the business managers cannot predict where the market will go. They don't have a crystal ball. No one is asking them to predict the future. Many times, what project you do next depends on whether you get a certain grant, or whether a certain bid is successful. Obviously. If you are working on business applications or creating a product that might participate in a suite of products, there are things you need to know. You need support from people with power regarding your plans. The people in power don't know this. Let them know it. It is impossible to build a service-oriented architecture in an organization without a long-term plan and the knowledge, input, and support of the business people who make decisions about your overall long-term goals. It is likely that they do not know or care what a service oriented architecture is. Show them the benefit, or the necessity, and tell them you need some information. Because you can't string apps together with tape. You need to consider a framework, and cross-cutting features such as authentication, authorization, customization, interoperability, platform support and reliance , and so on. And if your job is to write code, you almost certainly don't have the answers to these questions on your own. We in IT departments are in a tough spot. It is polite for us to suggest that we only exist to support the larger goals of our government, or our basketball shoe-making company, or even our software development company. This is obviously, trivially true. It is not the whole story. Business people do not think of us as a real department, such as Finance or Human Resources. They think of us as a meta-department. An expense. As if Human Resources or Finance or the Police Department is not an expense. If you work on business apps or infrastructure, you are not simply in product development. You're serving two masters, each of which only knows the other by its sordid reputation. And that politesse can actually be a disservice to the business. Demand to participate in the goals. Because IT is different: It is a separate entity and yet a meta-entity that touches everyone every day. Demand that the stake holders in an application are present and communicative. Software projects fail when organizations think that it is only the job of the software developers to make software. Stakeholders must participate. Management must provide resources and get behind projects. Customers must use the software. The IT department must understand the long-term goals of an operation, and make a long-term IT plan to support those goals. Often we go this far. But then we start working on our own and a black market springs up. Go a step further. Go back to the business people and get their buy and support of your plan. Route out the black market. | 