Okay, so I'm going to get topical, here. As a professional programmer, I have to present myself in the best light possible, but in any endeavor, you are truly trying to learn and explore, to find ways to grow in your chosen field, and in order to do that, you have to risk looking like you don't already
know the answers and instead learn to be naive again, asking questions and finding new solutions.
That's what I aim to do here.
I have worked as a programmer, a systems analyst, investigating business requests and creating requirements for other developers, as a project manager, taking a defined project and working with a team to implement the proposed solutions, putting out fires, managing change, and as a systems architect, taking existing systems of software and databases and deciding how things should be arranged, or rearranged, to work more effectively and to be easier to maintain.
The fundamental aim of any business is to generate more revenue than is being spent on overhead. You want to make a profit. Anybody involved in even small investments of money and time has learned that sometimes you have to work at a loss before you get the intended returns. You may go into debt to go to college or to buy a car or a house. But if the car enables you to get to a high-paying job, or if college enables you to make even more money than you would otherwise, it is worth the investment.
Somehow, though, in business, there is a push to get those returns sooner rather than later. Perhaps it is because there are multiple people managing different responsibilities: bosses delegate responsibility for executing a task, but maintain responsibility for budget, and so start putting pressure on their underlings to cut costs and get their projects out sooner. Or perhaps it is because projects so often lose momentum, due to red tape and endless meetings, thereby creating a sense that projects have to be completed soon, at the expense of well-prepared design, or they will never get done at all. Or perhaps it is because there is a sense of futility in trying to planning things well, because no matter how much you plan, someone will change things, now or later, making most of the plan irrelevant -- and how much is that helping the company's bottom line?
So one of the biggest tasks for anybody in a senior developer or project management role is to balance the concerns for the bottom line with the real benefits of taking the time to plan, to design and to anticipate future needs.
An example: Someone comes to you and asks for a web application that brings up customer orders. All they want, they tell you, is to have the orders displayed along with the customer name and phone number in case they need to contact the customer when there are problems.
Easily done.
But what happens if you later on get a request to include the ability to add new customer records? Or to update the customer phone number once you've learned of a change?
What happens if your company starts taking clients who want you to manage their customers, as well? There are database tables already in existance which describe the customer, the orders they have made, the money they have paid. Now you have a decision to either use these existing tables, adding a field in the data table designating them as your customer, or your client's (and what happens if you both have that customer at different times?), or to create an entirely new system of tables, maybe based on your existing one, but only used for your client's customers?
Your decision maker is going to be struggling with the impulse to make this change quickly, while minimizing the chance of bugs occuring in your software. And one basic premise in software design is
not to just copy and paste your existing code and data tables so you can have one work for your client. Why? Because now, any time you have to make a change, you have to make the matching change in your other copy of the code. Twice the work.
But I can tell you for a fact that, no matter how much the best intentions will be to modify applications to work flexibly under both circumstances, the interest of trying to get that project done sooner so you can start making money faster will always result in some or most of your problems being solved by copying entire bits of code, adding columns to an already big data table, including specific bits of code to handle one client's specific needs.
This blog is about these problems. It's about software development as a career. I will post occasional blogs about my own day-to-day challenges and discoveries, about questions or theories I am pondering, about articles I have read. About how and why programming solves our daily business and personal problems, and how things can be managed better.
