Skip to main content

Posts

Showing posts from February, 2006

Your priorities are what you DO

Do you ever wonder how you are meant to work on high priority long term tasks when you seem to have a never ending list of "urgent" (but non-important) tasks to work on? Mark Horstman from the excellent Manager Tools podcast has a few words to say on the matter . My key takeaway from his post is: What is it that you DO? How do you spend your time? Because what you DO really IS what your priorities ARE . This really hits home on what you should be doing rather than what you are doing. It also indicates why it can start to get you down when you don't get to work on the them. Mark covers this when he says: The disparity between what they know their jobs to be and what they spend their time doing is the primary source of their dissatisfaction in their role. What you need to do is figure out how to spend less time dealing with the non-important but "urgent" work and more time on the important strategic stuff. Stephen Covey covers this with Habit 3 : "Put Fi

Google Page Creator - Nice & Easy! Unsafe

I discovered Google Page Creator this morning (via the technology section of memeorandum ) and then spent the next 5 minutes signing up and creating my first GPage. Check it out! It looks like a very simple, easy to use tool that will make creating webpages very easy for non-techies (but you can still get access to the raw HTML for those more tricky issues). Update: In my haste to spread the word I failed to notice something pointed out over on the One Degree blog , your Gmail username is part of your URL so it's trivial for spammers to figure out your Gmail email address. Technorati Tags: Google , Page Creator , Website Design , Andrew Beacock

Why do you want that feature?

37signals have got their heads screwed on the right way. Over on their Signal vs. Noise blog Jason has posted about why they have many 'features' missing. His response: "It just doesn't matter" . Their latest product is "easy group chat for business" called Campfire . It's a web-based IRC-type service which allows you to chat, share files and pictures. They have left a large number of so called 'features' out and many people have been asking why on their forum. They take the view that if it's not essential for the service to operate correctly then you have to make the hard decision of whether to include it or not. Any feature no matter how small costs, whether in time, complexity of the resulting code or in the usability of the final product. When you are designing software for someone other than yourself how do you take the same approach? If they are paying the wages then surely what they want wins? My thoughts at the moment revo

Restricting Firefox's memory leak usage

There has been a lot written recently about the "memory leaks" of Firefox 1.5 . The lead engineer for Mozilla Firefox, Ben Goodger posted about this over on the Inside Firefox blog . Apparently one possible "leak" is actually a feature - Firefox caches a number of the previously viewed pages in memory so that should you want to go "back" they don't have to be downloaded again. Obviously this can be a tremendous performance boost when going back but the default rules that Ben posts abouts got me a little concerned. Here is a table of the system ram size and the default number of cached pages: RAM Number of Cached Pages 32MB 0 64MB 1 128MB 2 256MB 3 512MB 5 1GB 8 2GB 8 4GB 8 As you can see if you have 1GB of RAM or above it will cache 8 pages by default, but if you have 512MB then it will only cache 5. I have 1GB in my machine but will be caching the same about in memory as a 4GB machine - so I changed this setting to only cache 6 pages. Here's

Webapp design hints & tips from the del.icio.us founder

Joshua Schachter presented at the The Future of Web Apps summit in London this week and both Peter Cooper & Simon Willison have posted some excellent notes from that session. The key findings from these notes for me are: Keep URLs simple. Leave all the framework invisible, it doesn't help the user, keep URLs clean. "Nobody cares" about complex URLs. Some latency in the system is OK - work out where you have leeway, e.g. RSS feeds can fall a few minutes behind without anyone minding. Keep API simple - REST, etc. When people ask for features, get to the bottom of why they are asking for that exact thing. Solve the problem, rather than doing exactly what your asked for. The features you put in are as important as the ones you leave out. Don't waste time building features nobody uses. These cover similar points to the ones I raised in yesterday's post about stripping requirements down to the bare-bones . Technorati Tags: del.icio.us , Joshua Schach

Stripping requirements down to the bare-bones

Jason Fried of 37signals posted recently about how they choose the essential vs. non-essential requirements for v1.0 of their products. This got me thinking that: a) what a great idea, it makes perfect sense b) how many client-driven projects would allow such a thing to happen? With agile development and the process of release & iteration planning in particular, essential requirements would be moved in front of non-essential ones, so maybe when dealing with external client-driven projects the first iteration (or so) would produce the 37signals' v1.0 release? Technorati Tags: Jason Fried , 37signals , Agile , Release Planning , Iteration Planning , Andrew Beacock