Don't Touch that Code!

Don’t Touch that Code! It has happened to everyone of us at some point. Your code was rolled on to the staging server for system testing and the testing manager writes back that she has hit a problem. Your first reaction is “Quick, let me fix that — I know what’s wrong.” In the bigger sense, though, what is wrong is that as a developer you think you should have access to the staging server.

Encapsulate Behavior, not Just State

Encapsulate Behavior, not Just State In systems theory, containment is one of the most useful constructs when dealing with large and complex system structures. In the software industry the value of containment or encapsulation is well understood. Containment is supported by programming language constructs such as subroutines and functions, modules and packages, classes, and so on. Modules and packages address the larger scale needs for encapsulation, while classes, subroutines, and functions address the more fine-grained aspects of the matter.

Floating-point Numbers Aren't Real

Floating-point Numbers Aren’t Real Floating-point numbers are not “real numbers” in the mathematical sense, even though they are called real in some programming languages, such as Pascal and Fortran. Real numbers have infinite precision and are therefore continuous and non-lossy; floating-point numbers have limited precision, so they are finite, and they resemble “badly-behaved” integers, because they’re not evenly spaced throughout their range. To illustrate, assign 2147483647 (the largest signed 32-bit integer) to a 32-bit float variable (x, say), and print it.

Fulfill Your Ambitions with Open Source

Fulfill Your Ambitions with Open Source Chances are pretty good that you are not developing software at work that fulfills your most ambitious software development daydreams. Perhaps you are developing software for a huge insurance company when you would rather be working at Google, Apple, Microsoft, or your own start-up developing the next big thing. You’ll never get where you want to go developing software for systems you don’t care about.

Hard Work Does not Pay Off

Hard Work Does not Pay Off As a programmer, working hard often does not pay off. You might fool yourself and a few colleagues into believing that you are contributing a lot to a project by spending long hours at the office. But the truth is that by working less you might achieve more — sometimes much more. If you are trying to be focused and ‘productive’ for more than 30 hours a week you are probably working too hard.

How to Use a Bug Tracker

How to Use a Bug Tracker Whether you call them bugs, defects, or even design side effects, there is no getting away from them. Knowing how to submit a good bug report and also what to look for in one are key skills for keeping a project moving along nicely. A good bug report needs three things: How to reproduce the bug, as precisely as possible, and how often this will make the bug appear.

Improve Code by Removing It

Improve Code by Removing It Less is more. It’s a quite trite little maxim, but sometimes it really is true. One of the improvements I’ve made to our codebase over the last few weeks is to remove chunks of it. We’d written the software following XP tenets, including YAGNI (that is, You Aren’t Gonna Need It). Human nature being what it is, we inevitably fell short in a few places.

Install Me

Install Me I am not the slightest bit interested in your program. I am surrounded by problems and have a to-do list as long as my arm. The only reason I am at your website right now is because I have heard an unlikely rumor that every one my problems will be eliminated by your software. You’ll forgive me if I’m skeptical. If eyeball tracking studies are correct, I’ve already read the title and I’m scanning for blue underlined text marked download now.

Inter-Process Communication Affects Application Response Time

Inter-Process Communication Affects Application Response Time Response time is critical to software usability. Few things are as frustrating as waiting for some software system to respond, especially when our interaction with the software involves repeated cycles of stimulus and response. We feel as if the software is wasting our time and affecting our productivity. However, the causes of poor response time are less well appreciated, especially in modern applications. Much performance management literature still focuses on data structures and algorithms, issues that can make a difference in some cases but are far less likely to dominate performance in modern multi-tier enterprise applications.

Keep the Build Clean

Keep the Build Clean Have you ever looked at a list of compiler warnings the length of an essay on bad coding and thought to yourself: “You know, I really should do something about that… but I don’t have time just now?” On the other hand, have you ever looked at a lone warning that just appeared in a compilation and just fixed it? When I start a new project from scratch, there are no warnings, no clutter, no problems.