Click here to Skip to main content
15,126,367 members

Welcome to the Lounge

   

For discussing anything related to a software developer's life but is not for programming questions. Got a programming question?

The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.

 
GeneralReal life angry birds Pin
Wendelius8-Oct-11 12:30
mveWendelius8-Oct-11 12:30 
GeneralRe: Real life angry birds Pin
AspDotNetDev8-Oct-11 13:22
protectorAspDotNetDev8-Oct-11 13:22 
GeneralRe: Real life angry birds Pin
Steve Mayfield8-Oct-11 15:12
MemberSteve Mayfield8-Oct-11 15:12 
GeneralRe: Real life angry birds Pin
Chris C-B8-Oct-11 20:05
MemberChris C-B8-Oct-11 20:05 
GeneralThe Spolsky Score Pin
Rob Lyndon8-Oct-11 7:02
MemberRob Lyndon8-Oct-11 7:02 
GeneralRe: The Spolsky Score Pin
wizardzz8-Oct-11 7:48
Memberwizardzz8-Oct-11 7:48 
GeneralRe: The Spolsky Score Pin
Eddy Vluggen8-Oct-11 7:57
professionalEddy Vluggen8-Oct-11 7:57 
GeneralRe: The Spolsky Score Pin
Rob Lyndon8-Oct-11 18:44
MemberRob Lyndon8-Oct-11 18:44 
For sure. 1 to 5 are absolutely indispensable, and 9 to 12 are very important. As to 6, 7 and 8, I'd say that depends on the nature of your business.

Let's have a look 6, 7 and 8 in a bit more detail.

6. Do you have an up-to-date schedule?

I don't disagree with this one, but I will point out that schedules can sometimes change very quickly. I remember working on a financial application, when a change in the law came in, and we had to add a component pretty much yesterday, in order to keep the FSA off our back. (OK, that might be a slightly bogus example, because as any regular reader of Private Eye can tell you, the FSA is often perceived as more of a kitten than a lion, but run with me for now.) So when requirements like this come in, your schedule needs the flexibility to keep up with the changing landscape.

Another thing to point out is that you may be in an outfit where you're expected to know the business well enough to come up with your own ideas, and present them to the business accordingly. If you have enough reusable components, and you have built your system from the ground up using the right set of best practices, you'll be surprised how quickly you can release a component. We used to play the "start the clock game" in our team. When a requirement came in, we could sometimes fulfil that requirement by making config changes, generating a couple of derived classes, and adding one or two lines of code. Because we were adding very thin layers on top of code that was already thoroughly tested and trusted, we had a high degree of confidence in what we turned out, and could target our testing accordingly.

I guess what I'm saying here is yes, keep schedules, but don't let them constrain your creativity: they're there for your benefit, not the other way around.

7. Do you have a spec?

You can go a very, very long way by naming libraries, classes, methods and variables intelligently, and by observing the Single Responsibility and DRY (Don't Repeat Yourself) principles. Again, if you're working on an internal app in a small team, then if you have a straightforward method for code reuse that you've all bought into, then the need for a spec starts to fade. Under those circumstances, enforcing a "no code without spec" rule feels like you're adding unnecessary red tape to an already efficient process. On the other hand, with a larger team and thousands of users, a spec can add an indispensable layer of clarity to your project.

My attitude to schedules and specs is similar: use them, but do so intelligently, and only to the extent that they serve the needs of your project.

8. Do programmers have quiet working conditions?

I haven't read "Peopleware", and maybe I should, but Joel's argument runs against my experience for several reasons. First of all, I would debate his assertion that you need to be "in the zone" to be doing your best work. Once again, if your project is very well structured, and you have been sticking to the Single Responsibility and DRY principles, it will definitely not take fifteen minutes to get back to full productivity after an interruption. This is an important distinction. If you're trying to battle your way through an impenetrable melée of spaghetti coding written by your cowboy co-worker Joe McHackburger, there's no other way through than to put your headphones on, immerse yourself in the code and appoint a security guard to repel anyone who might interrupt your flow of thought. It's just that if you're in that situation, I'd say something has gone wrong already, and you're missing out on two very important benefits of working in a communicative environment.

First of all, I cannot stress enough the importance of DRY. In my experience, the most costly, time-consuming and elusive bugs have all sprung from different parts of your code base trying to do the same thing, but using different code paths that generate subtly different results. You can try to avoid this problem using specs, but in the teams I've worked on, the best way to avoid code duplication is to stand up and ask. If I needed a bank holiday counter when I was a novice coder, I would try to find one online or just generate one myself. On the teams I've worked for recently, we've had a culture where it's perfectly acceptable practice to stand up and say, "Hey lads, has anyone got a bank holiday counter?" The benefits of doing so easily outweigh the costs.

The second benefit depends on the kind of project you're working on, but I refer again to my experience of working in a trading environment. As a developer in one of those outfits, you're not working in a bubble. It is absolutely in your interest to keep an ear open to every conversation that is happening around you, because that is where some of your ideas are going to come from. This is why spaghetti code can be so toxic: it cuts you off from your surroundings, and your surroundings are the source of your business.

I'm reminded a little of Rudolf Laban's experience when he fled the Nazis and came to England. He'd been an avant-garde choreographer in Germany, and he'd become passionate about understanding all forms of human movement. Arriving in Dover in his late fifties with only the clothes he had on him, he had to make a living very quickly in a new country. Initially, he found help from former colleagues at Dartington Hall, but his expertise in movement gave him the ability to work in industry, helping factory workers to find optimal ways of working. Up until Laban's arrival, most of the work done in that field had been based on time and motion studies. The stopwatch had become the most important unit of measurement in the factory, but the problem was that the time and motion studies didn't seem to be working. There was little or no increase in productivity, and workers were neither healthier nor happier, despite exhaustive efforts to minimise the amount of physical work they were having to perform. Laban realised that there was something fundamentally wrong with the time and motion approach. His life up until then had been about realising the full gamut of human movement. He had isolated four dimensions of movement: time (quick or sustained movement), weight (strong or light movement), space (flexible or direct movement), and flow (free or bound movement). His choreography had spanned the full range of each of these dimensions, and one of the things it had bred was extremely fit and healthy dancers. Applying the lesson to industry, what Laban realised was that workers also needed to go through the full range of the four dimensions. Time and motion studies had constrained their activities, resulting only in injury, poor health and loss of productivity. By throwing away the stopwatch and structuring the workplace in a way that allowed workers to shift between quick and sustained, strong and light, flexible and direct, and free and bound states, Laban achieved results that contributed directly to the war effort, and gave him his financial independence.

That's a fairly long-winded way of saying that working only in one groove is not good practice, either for yourself or your business. It's funny: Joel's throwaway comment about unfit programmers, though not intended to be serious, is actually more revealing than it was intended to be. It is not good for you to be "in the zone" eight hours a day, five days a week, forty-nine weeks a year. Your business will not be served, your health and fitness will suffer, and you run the risk of becoming a crushing bore. Don't do it. Find another way of working.
GeneralRe: The Spolsky Score Pin
Rob Lyndon8-Oct-11 19:23
MemberRob Lyndon8-Oct-11 19:23 
GeneralRe: The Spolsky Score Pin
Eddy Vluggen9-Oct-11 4:12
professionalEddy Vluggen9-Oct-11 4:12 
GeneralRe: The Spolsky Score Pin
harold aptroot8-Oct-11 8:07
Memberharold aptroot8-Oct-11 8:07 
GeneralRe: The Spolsky Score Pin
Rob Lyndon8-Oct-11 18:59
MemberRob Lyndon8-Oct-11 18:59 
GeneralRe: The Joel Test Pin
Nicholas Butler8-Oct-11 8:46
sitebuilderNicholas Butler8-Oct-11 8:46 
GeneralRe: The Spolsky Score Pin
AspDotNetDev8-Oct-11 11:26
protectorAspDotNetDev8-Oct-11 11:26 
GeneralRe: The Spolsky Score Pin
Dan Neely9-Oct-11 15:25
MemberDan Neely9-Oct-11 15:25 
GeneralRe: The Spolsky Score Pin
Gary R. Wheeler9-Oct-11 4:25
MemberGary R. Wheeler9-Oct-11 4:25 
GeneralHow to Train Your Dragon [No Spoilers] Pin
Abhinav S8-Oct-11 6:42
MemberAbhinav S8-Oct-11 6:42 
GeneralRe: How to Train Your Dragon [No Spoilers] Pin
Ian Shlasko8-Oct-11 6:48
MemberIan Shlasko8-Oct-11 6:48 
GeneralRe: How to Train Your Dragon [No Spoilers] Pin
CalvinHobbies8-Oct-11 6:52
MemberCalvinHobbies8-Oct-11 6:52 
GeneralRe: How to Train Your Dragon [No Spoilers] Pin
Rick York8-Oct-11 15:03
mveRick York8-Oct-11 15:03 
GeneralRe: How to Train Your Dragon [No Spoilers] Pin
thatraja8-Oct-11 22:57
professionalthatraja8-Oct-11 22:57 
GeneralRe: How to Train Your Dragon [No Spoilers] Pin
OriginalGriff8-Oct-11 6:55
mveOriginalGriff8-Oct-11 6:55 
GeneralRe: How to Train Your Dragon [No Spoilers] Pin
Abhinav S8-Oct-11 7:13
MemberAbhinav S8-Oct-11 7:13 
GeneralRe: How to Train Your Dragon [No Spoilers] Pin
OriginalGriff8-Oct-11 23:13
mveOriginalGriff8-Oct-11 23:13 
GeneralObject Null Reference... PinPopular
Sander Rossel8-Oct-11 5:25
professionalSander Rossel8-Oct-11 5:25 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.