Recently in Work Category
A point very near and dear to my heart at present, given that the decision has been made recently to add icons to buttons in an application (web-based) I'm currently working on. Needless to say, my personal opinion is that this spoils the look of the app, particularly as the icons being used aren't visually styled in the same way as the menu icons and the other graphical components of the UI. It looks very, umm, Windows 95 with Borland developed apps. Ugh. Le sigh.
The Promise and Peril of Jumbo Frames
I suppose I should try this on my network at home as hoiking huge 350Mb+ files around does tend to be somewhat painfully slow. It's a shame that the curse of backwards-compatibility makes things like Jumbo Frames so difficult to implement easily.
[Via: The JobSyntax Blog]
I came across an interesting blog entry (linked below) that discuss how to keep software developers / engineers (pick your preferred terminology) happy. Pretty much spot on I'd say! Software by Rob: Nine Things Developers Want More Than Money
Also, another posting by the same guy regarding expectations and the management of them. Expectation management is something that rarely seems to happen in software development, very often the disconnect between the expectations that Sales teams have and the reality that the development team can deliver is phenomenal. Attempting to match these up can lead to some very tense moments. Software by Rob: Why Expectations Can Kill You and What You Can Do About It.
Well, the beginning of the end anyway... In a lot of other countries charges for banking are the norm rather than something unusual, maybe this is the first step in the UK going the same way. The banks have got to recoup the money they're loosing on reduced credit card fees after all!
[Via ScottGu's Blog] Ten Worst Presentation Moments
The IM notification one really made me smile.
Sure I've waffled about this before, but there's an article on StickyMinds.com titled "Win-Win Delegation" in which the most important (to my mind) point is "Delegate Authority with the Task". There's nothing worse than giving someone a task to do, but not the tools they need to do it, and authority is just another tool at the end of the day. (A very important tool admittedly!)
[StickyMinds.com] Done and DONE-done - The Magic of Completion Criteria
Another great article from stickminds, which shows the importance of defining requirements, in this instance work completion requirements. Someone I work with uses an example of "the client wants a login box", fairly simple requirements you'd think? Think again...
Grand Designs (on Channel 4 on November 2nd 2005) was all about a build in Belfast. After having seen the organised chaos that is many of the other builds that Grand Designs has showcased, this one was simply amazing. Not only did they finish for the planned date, they also came in under budget! This being despite them running anywhere between 2 hours (yes, their schedule was that tightly planned!) and 2 weeks behind at various times. I guess they really did prevent late tasks from creating late projects. I'm not quite sure how any of the principles in the linked article from Sticky Minds applies to the Grand Designs build, if indeed any do. But, it certainly makes for interesting reading.
The one point that is clearly common between the two though, is that whatever the project, the person managing it has to have their eyes on the ball 100% of the time. Even the shortest amount of time without that focus and it can all start to come rather horribly unravelled.
Time -- Time Management Tips for Developers
Collect all tasks in a to-do list -- I started doing this fairly recently (in part prompted by an internally delivered training course I went on) and it's actually made a bit of a difference. It certainly makes the work-load I'm dealing with *feel* like it's more manageable. It also makes it seem like I've achieved more when I can see a list of items crossed off a list.
Delegate when feasible -- Something that I know I don't do as much as I should do. "Dump It. Delegate It. Do It". The three options I was told to use (in the same training course!) whenever a task comes my way. I'm a hoarder at times. I keep tasks for myself because I think that I'll be able to do them better and quicker than anyone else. Mistake. Repeat after me, "Others can do the job too."
Identify your Timewasters -- Is someone dragging the rest of the team down? If they are, is it even their fault? Maybe they're out of their depth. Maybe they don't like the job they're doing. Maybe they're just bone ideal. All people have a working style, some peoples working styles just aren't right though. Changing a persons working style is one of the hardest things to do, the soft option is to manage them out of the business.
Reward Yourself -- (and your team!) Nothing provides for team motivation and cheer than a reward of some kind. Even a thankyou can be a reward. It's surprising how many people don't say "Thank You" for a job well done at work!
Developers -- Semack.Net - On Being a Manager
Keep Everyone Pointed in the Right Direction -- It's all too easy in a big project for people t o take divergent paths. Requirements are easy to interpret in any one of a thousand ways. Many things can be implemented either in a very simple way, or in a very complicated way. The very complicated way often has a lot of benefits associated, but, will they ever be used? To a developer the complicated way is good, because it is. To a development manager the simple way is good, because its quick and will bring the project in on time/budget. To the good development manager, the middle road that follows the same path as the rest of the development team, utilising any pre-existing code and best practice. This is also the way that was planned out and documented prior to the start of the project.
Double-Check Everyone's Work -- This ties back to keeping everyone pointed in the right direction. There's such a thing as "Specification Creep" and hand in hand with that comes "Implementation Creep". As well as checking to make sure a piece of work has been implemented correctly (including following any development / coding guidelines in place) and in an efficient manner, ensuring that what's been done actually fits the specification is just as important.
Evaluate Employees -- This applies to everyone, not just developers. Spend some time talking to your team. Coaching and guidance should be a constant and ongoing thing, but, always take time to block out 15 minutes a week to touch base with each person in your team. Use the time to find out how things are going, to deal with their concerns and to track their professional development. Annual appraisals are all well and good but everything that gets written on the appraisal form should be things you've discovered and discussed during the year previously. An appraisal shouldn't have any surprises for the appraiser or (especially!) the appraisee.
Most of this is a reminder to me. Things I should do. Practices, process and procedures I should implement. I just need to make sure I do it now!
A couple of good articles regarding the art of managing email. [via: Jonathan Hardwick: Shipping Version One]
Potentially the best line is in the first article and has to be:
One CEO I've worked with charges staff members five dollars from their budget for each e-mail she receives. Amazingly, her overload has gone down, the relevance of e-mails has gone up, and the senders are happy, too, because the added thought often results in them solving more problems on their own.
Quite how I got to here, I'm not sure. But, it made me think about the ways of writing "good" defect reports. For a Tester/QA person to write a good defect report, they have to be able to describe how the problem they've encountered occured and the exact steps to reproduce it.
Keeping a Lab Notebook style record seems like a pretty good way to do that.
I found a useful bit of information regarding Microsoft Visual SourceSafe (VSS) today here, describing what a "Cloaked Project" is - I'm definately going to find this useful for various job related things I do as there are a fair few nodes of the source tree that I seldom need. (such as the source-code for pre-compiled components)
One interesting use for VSS is as a documentation management system, in lieu of a package specifically designed for the task. Whilst it's "better than nothing" it definately has its shortcomings. Over a period of time, many different versions of the same / similar files get created by different people, generally for the same well intentioned reason, but it does tend to result in a tangled folder hierarchy. Sorting out / tidying something like this becomes a bit of a mammoth undertaking, to say the least!!
How about creating a structure, what kind of structure would be best... If you have a product that iterates through versions, with each client generally having every other version of the product, what's the best structure to store documentation? (For example, Clients A & B tend to have the even-numbered releases and clients B & C tend to have the odd-numbered releases) Do you have a ROOT > VERSION > CLIENT structure, or a ROOT > CLIENT > VERSION structure, or something more complex?
A potential structure is ROOT > VERSION > CLIENT, accompanied by ROOT > CLIENTS > CLIENT for non-version specific documentation, such as Contracts and the like, and in the ROOT > VERSION > CLIENT structure, you either store the "generic" documentation for that version in the VERSION folder, or a "GENERIC" sub-folder thereof. What about non-client, non-version specific documentation? Is there even such a thing? Surely any piece of documentation should be created for a specific version and then copied to the later version and updated if required,... but then should the same apply to generic documentation.
Let's say that the product is a Cake. The base recipe might undergo changes between versions, with bespoke "patches" applied for some clients. For example, clients A & B might have the cake plain, client C might have it with an "icing-on-the-top" patch, and client D might have it with a "chocolate-flavour" patch,... Should the generic recipe be kept in a GENERIC folder, or copied four times, once into each of the clients folders?
Documentation management gives me a headache.
--------
