Last week Mike Vizdos wrote an article at Implementing Scrum.com that had me scratching my head a little. In this article Mike was arguing that Silence is a symptom of poor communication, and that when team members have conversations over messenger, those that would gain collateral information from the conversation would be shut out from such juicy bits.

One of my colleagues once walked into a room with a new team. When he told me about it, he said something along the lines of, “It was so quiet you could hear the waterfall.”

Think about that last statement for a moment. I’ll stick around.

Welcome back. Good thought break? Hope so.

When *I* hear this statement, I realize a team is probably not working to its full potential.

While not the Uber scrum master Mike is, I don’t think he understands the psychologies of programmers to realize that ambient conversations are going to murder their performance and concentration. When I initiate a conversation with a person over IM that is in the same office, it gives them the ability to multi-task and not be thrown off their process completely.

I’d basicly equate this to trying to program with the TV on. Some of us can do it, some of us can’t, but nobody is as productive with it on, as with it off.

A lot of the rules of Scrum are really important, transparency between client and team, team and scrum master, team and team are super important, but were not the Borg. And there are only so many hits performance can take in the name of transparency before Scrum starts to become a hindrance.

Long live IM!

So I wrote that Singleton post a few weeks ago, and what it really turned into is how to initialize Static Properties. Though calling it a Singleton post really makes you look kind of silly, since its a piss poor example of that.

Here is the Class Diagram from Wikipedia for the Singleton Pattern

To break that down, we have a Public Instance Function that retrieves the singleton instance, and a private constructor so the object can only create itself.

In the example I gave earlier, you can’t have a private constructor, and you can still call the public constructor again after the singleton has been defined. I was really excited to see that the new Prototype 1.5 library that was released (maybe the old one too, I’m just starting to get into it) contains some classes such as the Position class that have no public constructor, and are available without having to construct them initally.

How did they do this I wondered. A quick dig into the library shows that Prototype just uses the inline object syntax, which makes the Position class just an object instance, which of course has no constructor.

var Position = { “Methods” : function() { /* */ } }

I really like this a lot better, and I’ll probably be utilizing it a bit more in the library for our companies product. I’d love to see more libraries out there that you can include and you would get these specialized functional classes. Prototype’s Position is really helpful, what else could we want?

If you view enough of my Javascript, you’ll notice, I like to comment my code a little differently then the other developers at our company.

My main purpose of doing this is to track comments that just I make. I also want to be sure that I did or did not perform any working a certain area. Or to just make comments to myself. I’ve seen comments like, // Edited by Bill Gates 10-20-2003: I fixed a bug here, and yes those serve the same purpose, they are even more descriptive, but they how many of you do that currently? Source control will tell me when a changed occurred and who fixed it, I’m mainly worried about my own train of thought, and notes.

Here are the signatures I use.

//— Generic comments.

//# Todo comments

I don’t have a signature for /* */ style comments, and the Todo comments are for NON crucial todo tasks only. A good old / / TODO: still is king for those.

For those of you with no Imagination, here are some for you guys to pick from.

//> Whats this supposed to do?

//\\ My little house here says, this code rules!

//oo I just infinitely commented my code!

//=D Smile! This code just took a picture of you!

If you adopt a comment signature, post!, share!

This blog has moved. You can read this post here.

Its my New Years weekend vacation and I’m reading reading these juicy programming articles. Beware, full of naughty goodness.

AJAX Patterns – All about AJAX, quite helpfull.

43 Folders Wiki – Productivity wiki for the software development field.

Reflector Addins – Code Generation, Code Coverage, Code Graphs, man look at them all.

The Peoples Toolbox – Usefull tools for developers

0Rand 1, 0Rand 2 – Two great articles by this guy, Article 1, debuging with Reflector and Visual Studio, debug lower level components you don’t have source code for. Article two, debunking my statements that us developers need offices to be more productive.

WPF versus WPF/E – Interesting comparison with some sample code.

The Dojo Toolkit in Practice – Intro to Dojo

Superfoods everyone needs – Eat healthy!

and our company is asking for more.

We’ve been contracting developers and testers overseas, known for the length of this article as Initech. (Wha?) So like I said, we’ve been using Initech for the majority of our support issues, and then using them to make up large portions of our development teams. The former, while a developers dream (never have to fix a bug in released code, holy cow) is eventually going to lead to shoddy quality and less attentiveness on the behalf of the in-house development team.

As a result, Test driven development and even more importantly any real refactoring attempts are ignored by management, and not voluntarily adopted by the majority of the development team. Test driven development will catch the majority of your issues at dev time, and ensuring quality in following builds through the magic of continuous integration. Since we aren’t writing our tests first our coverage is quite low based on our weak testing discipline, but a much bigger result is that we are not performing the third step of TDD, which is Refactor Ruthlessly.

What we’ve got now is a bunch of weakly tested, ugly, smelly code that we just need to mangle enough to produce the functionality we want, without having to worry to much about the long term quality issues.

I know what your thinking, excuses, excuses. Good developers should refactor, they don’t need a reason, they have the motivation to have quality code developed and part of that is refactoring. There are other factors, and since this is an outsourcing rant and not a refactoring rant, I can’t go into those fully yet.

The Initech guys really are talented, I’m impressed by what they can do, especially under the conditions we impose upon them. Yet they have serious lapse in their completeness. Such as jobs being reported as done just being skipped, functionality being skipped, holes in the design going unnoticed all killing us overall.

Our in house development staff is spending a large portion of their time reviewing, fixing, and completing Initech code. Add these extra duties, to the new demands of scrum, we are finding the amount of time we get to actually code is being severely decreased which leads back to in house developers not having the ambition to self impose TDD and Refactoring into their day to day efforts.

Less apparent is the effect this is having on employee moral. You can argue developers ambitions for their work but whatever they are, this process is ruining it. Our code isn’t something to be proud of, our day to day operations are contain less coding and we’re producing less of those glorious features everyone praises us for. Would it surprise you to find out we’ve had some key people leave in the last few days?

I may make outsourcing seem like the root of all evil, I don’t think we need to do away with them, but with our current process, structure, and personnel, we cannot handle the work load given to Initech. They are great tools for supporting our current in house development team, but history has shown that we can’t trust them on a consistent basis. I hope the message can be relayed to the top, otherwise life as an Initech babysitter will continue to suck.

A quick note of a nice tool for us javascript developers.

The Dojo toolkit team has their own Javascript Compression tool that is available online at

http://alex.dojotoolkit.org/shrinksafe/

On my (modest) site Justise.com I have one larger Javascript file for my start menu from those guys at Milonic that I wanted to compress and here is the screenshot of the results.

You can see the results are quite impressive.

To solve your case of the Mundays

Dzone.com – A compilination site of diffrent articles by fellow developers for other developers.

Prototype documentation – Prototype is a javascript library that makes javascript a bit easier to use. Its hard to find good Prototype documentatio, so this site is a treasure trove.

Best of the Best 2.0 – The best 2.0 applications out there, grouped by category.

Javascript Libraries – My secret stash of libraries that make me seem like I’m uber productive, but really I’m just using other peoples hard work.

Balls of Fury! – For your viewing pleasure. Fun stuff.

That should keep you busy for weeks.

So its that time of year again.

My experiences with this practice are limited, as I have only had to fill out one of these before in my professional career. So my maturation process in writing these documents needs to be quite substantial this year.

Last year I took my usual timidness into my self review, trying to be meekly honest about my performance, modest about my skills and positive twoards the company. In my meeting with my manager, it turned out be a decent review overall, I had just gone through a nasty development cycle smelling pretty good and so they had positive things to say about my performance.

This year, I’ve been bitter about somethings for quite a while and took my self review as my opportunity to really chew into the meat of these issues (In addition to a few asses). I can’t tell you about the post review meeting with my manager yet as I haven’t had it, but I do want to go over some of what I put into it and my afterthoughts.

• Slightly Jovial

On some of the sections I just didn’t feel like making comments, how much do I really need to say about how good I am at Teamwork? Heck I said I was good at teamwork last year, and I think the manager downgraded my grade, so on these fuzzy topics, who really cares what goes in there?

So for better or worse, I made a few light hearted comments. I’m hoping they won’t think I just didn’t give a serious review, because I was quite serious, but I just didn’t feel that anymore needs to be said.

• I’m so good.

So in our review we have a few sections like Quality, Teamwork, Attitude, etc, that you need to grade yourself as either Exceptional, Strong, or needs Improvement. Now if your being reviewed–and lets be honest, we know money is on the line here–and you need to rate yourself, why would you put anything less then a glowing review of yourself? If you seriously need help with something, I could understand, but if your strong in any subject why would you not rate yourself Exceptional and have your manager bring down to what their ratings of you are.

• Give me my 10 things

My employer really is great to work for, they do so many wonderful things that it almost seems wrong to be critical of them. Yet things aren’t going to change without some kind of push, and this review was the perfect time to launch such a push.

If you want to know what I mentioned, go read this post.

• Help me, help you.

I know I still haven’t blogged about my adventures to a become a senior dev, but that quest is not dead. I did want to let my employeer know that they have not given me any indication what areas I need to improve upon, so I’m kind of flying blind. I’m thinking I’ll learn the cool stuff that is out there, make sure I pretend to be a senior dev and think happy thoughts.

I’ll post a follow up once I’ve had my meeting. I would love to hear about some of your experiences of self evaluations. Did anything work really well for you?

You need to be reading Coding Horror, Computer Zen, and Joel on Software.

Also, you need to read these following books immediatly.

Agile Software Development, Principles, Patterns, and Practices

The Best Software Writing I: Selected and Introduced by Joel Spolsky

Coder to Developer

That is all for now.

Oh and check out eProject.com too, its pretty cool stuff.