More Noise?

January 30, 2007

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!

Advertisements

Javascript Singleton Part II

January 27, 2007

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

singleton_classdia.png

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?


Script signatures

January 8, 2007

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!


Javascript Singleton using static properties

January 8, 2007

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


What I’m reading

January 1, 2007

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!


Our outsourcing is killing us

December 28, 2006

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.

 


Javascript Compression

December 19, 2006

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.

js_compress.gif

You can see the results are quite impressive.