In the time that I have developed software, I don’t know that I’ve ever met a developer who got excited about writing specs for anything. In fact, most developers loathe writing specs, or developing schedules of any kind. It’s not that they’re lazy, or that they don’t want to be held accountable; most of the time it’s because developers prefer to express themselves via code, or because developers are afraid that if they set a schedule, and then reality doesn’t match up, they’ll be forced to produce sub-standard code. Neither of these is an ideal situation.
This is directly at odds with the business need of specifications and schedules. Businesses need schedules to know when products will be finished and schedule things like trade shows, product launches, and write contracts with clients who need or want a particular product. It’s not as if businesses want to push their developers to insanity by forcing them to schedule and then stick to it; more often than not thousands of dollars hinges on the schedule, and it simply must be met.
If you ask most developers about source control, they’ll agree that it’s a wise thing to use. They’ll insist that they think it’s important. But yet, why are so many companies out there still not using source control in their projects? A good number of companies that I’ve worked with failed to make use of source control, resulting in issues that would have been trivial otherwise. In this article we’ll explore ways to make sure that if your company isn’t using source control, that you can help make a change to this policy.
Source control doesn’t need to come from the top
The first oft-considered misconception is that source control must be endorsed by upper management in order for developers to use it effectively. This is 100% incorrect. There are a number of ways that developers can make use of source control, even if management fails to embrace it, or rejects it altogether.
In software development, it’s crucial to track bugs and new features, and to be able to know exactly where a project is at any given moment. Bug tracking is crucial tot his goal; it allows a project manager to know what has been finished and what still must be done, as well as to outline to each developer their goals and responsibilities.
Most developers agree on the importance of bug tracking. Here are five tips I use when utilizing bug tracking.
Lots of marketing students and sales professionals each year are required to read the book How To Win Friends And Influence People and for good reason: the book stands alone as one of the greatest books on sales ever. I decided to co-opt the title of that great book for this entry, because I want to talk about how to sell your company to developers – particularly, how to get the best developers to do the best work and make your company, well, the best at whatever it is that you do.
Developers are not interchangeable.
If there’s one thing that’s absolutely frustrating about human resources types, it’s their insistence that problems can be solved by adding more people. To be fair, their role is to provide the human capital needed to get the job done; however, at the end of the day developers cannot be changed out like spare parts in an engine.
Often when I’m on a job interview, I’ll ask whether or not the company I’m talking with makes use of an automated build system of any kind. More often than not, the answer I get is somewhere along the lines of “build systems are irrelevant to the web; we can simply upload changes instantly.”
This thinking could not be farther from the truth. Build systems are just as relevant to the web (if not more so) than they are to compiled code. Build systems offer significant advantages to the development of software applications, and it is crucial that developers not take them for granted.
Shipping code that works is crucial to retaining the support of customers and high quality in your application. While it’s impossible to ship code without any bugs at all, it is possible to control for as many as possible, and fix as many known issues as there is time. These strategies are designed to ensure that code works when it is shipped to the end user.
Developers have a tendency to test their code only with expected data. Testers, on the other hand, aren’t developers themselves; instead, they will use data that you don’t expect and find bugs that your users might otherwise experience.