|
|
Re: I Know Why Software Sucks
|
Posted: Feb 27, 2008 11:48 PM
|
|
This is a subject that I have given an increasing amount of thought over as both a software developer and a manager over the last three decades. I've read a number of articles from David Platt, Damien Conway, Richard Stallman, Scott Berkun as well as yourself. Although each of you make a number of valid points, I feel strongly that there is a bigger picture that is being missed here.
As a software developer I went through various stages of reusing code, toolmaking and studying the latest development techniques that I could place into my programs. The problem was that the more intricate and complex my coding style, the more difficult it was to complete, the harder it was to debug and the less likely is was able to be maintained by someone other than myself. Also, the more complicated the program, the more likely that it would require a rewrite in the future. Over time, I had to learn to simplify the assignment down to its essential elements before I wrote a single line of code. This meant that I had to learn a lot more than how to write programs. I had to understand the reasons why I was writing the program in the first place. That meant that I had to understand the people that I was working for.
Believe it or not, the first thing that I realized when I became a manager was that I had to get smarter. Like most developers, I had a certain amount of contempt for management that had to be unlearned once I joined the club. Managers do not merely "chase cats". I had entered a world where I was required to answer rapid-fire questions from my superiors, obtain specs from users, schedule projects, keep a dozen programmers on a schedule and do it all at the same time. If I didn't do my job properly, I'd have a heck of a lot more to worry about than a few bugs in a program. Millions of dollars were potentially at stake. I had to learn to see a bigger picture.
After living on the other side of the fence, I now see software developers in a somewhat different light. The first thing that I notice is that developers whine a lot. They always want more contol, the latest tools, better specs, more testing and more time. Yet, they never seem to take advantage of what that they do have. A developer has almost complete control over his code as long as he can meet the project criteria. So why waste time working in more detail than is required to finish the job? Before you ask for more tools, ask yourself how well you are able to use the tools that you already have. Tools change on a yearly basis. Each new tool requires time to master its learning curve before the tool can become productive. Too many tools means too much time learning and not enough time working. Getting better specifications is a matter of motivation. Get out of the cube and learn from the people that need the program. Everyone will appreciate the effort. It will also make you a better developer. Also, the same people that you take the time to spec with will give you the time later to test. Finally, try to understand that deadlines are very important. One of the biggest problems in software development is that is has always been impossible to predict when a given project can be completed. When a project is late, corners get cut. Things that should be done properly often don't get done at all. Also, it is very difficult to justify doing more than the absolute minimum if the manager is being screamed at because the project didn't meet its deadline.
This response is an admittedly one-sided answer to a complex and multi-faceted problem. Management is at least as culpable in many other ways that I would like to discuss at a later time. The point that I am trying to make here is that sofware developers can directly work towards making the software that they create better by making an effort to see the bigger picture. Believe it or not, developers have a great deal of control over the quality of the software that they produce. Seeing the bigger picture will help developers to focus their best efforts on the features that are critical and avoid wasting time on distracting and time consuming details that nobody will care about two weeks later.
|
|
Previous Topic
