According to Guy Kawasaki, me and all my friends are better suited to be the next big thing than that wildly successful guy.
“Guys under thirty who are building a product that they themselves want to use.”
Ok maybe I blew the age requirement but at least I’m not wildly successful.
Joel explains why Human Task Switches Considered Harmful.
I could have sworn I posted this but wasn’t able to find it when searching so here it is for possibly the first time.
“It is better to have your preliminary work critiqued by your colleagues while there is still time to do something about it – no matter how difficult the criticism might be – than to have the finished project torn apart by strangers in public.”, Bill Buxton
Once again I’m messing around with the language that won’t go away. If you haven’t read these in regards to python, have a peek.
I’m not sure Alan Cooper created the concept of personas, however, he certainly contributed heavily. I’m a fan of Alan’s work and I’ve always liked personas.
Jason Fried, CEO of 37signals, comments on personas:
“Personas can’t make mistakes. Personas can’t make value judgements. Personas don’t use products. Personas aren’t real.”
Tough to argue with, however, isn’t working with personas a lot better than nothing at all? Following along, isn’t working with real users a lot better than personas?
According the site, John Reel is a “Renegade Super-Programmer”. I can’t confirm or deny that or any of the other claims on their site. What I do know is that he and his partner demo’d at the recent DemoCampGuelph3.
They demo’d an application they’d written to handle the installation of a php, server based web application that they sell. Nothing too exciting except for one key difference. They claim to have sold over 1500 copies of that software in less than a week. That’s a lot of different environments to install on.
If you’ve ever installed a php, web app then you know you typically ftp a zip to the server. Unzip/tar the files in a location. Play with permissions, add a database, set more permissions, etc, etc. The good apps have useful config pages which clearly explain to you at any stage in the process what’s wrong and what you can do to remedy the situation.
What John did was much cooler. They took it all out of your hands. Of course that requires you provide them with some serious credentials and full access to your server, however, you have the option of doing it all yourself if you prefer.
How could you possibly test and support the infinite number of server configurations out there? You don’t. In their case they tested 50 setups. Then they staffed a team of 7 developers around the clock to monitor client installations. When a client ran into issues, those developers fixed the issue for them. They then used the lessons gained to make the software better.
I like it because it’s a non-technical solution to a technical problem. Software companies can easily lose site of the available non-techie solutions available to them.
If you missed DemoCampGuelph3, sign up for the google group and join us next time.
“Making a plan and sticking to it guarantees a sub-optimal solution”, Andrew Fitzgibbon.
Ahhh so making a plan is bad? Writing code early is bad? I wonder where stalling and doing nothing fits in?
[Above quote originally read in Bill Buxton‘s Sketching book.]
Your last reminder that we’re running our third DemoCamp here in Guelph tomorrow night (Wednesday), details here. We should have lot’s of free food this time around so join us if only for the free grub.
If you’re asking me, where design fits in the software production process and what it actually looks like is one of the biggest issues facing the technology world. It’s a human problem and will not be solved with processes and tech tools. Alan Cooper chimes in….
“Generally the last thing you should do when beginning to design an interactive system is write code”, Bill Buxton.
I can’t really argue with Bill on this one. Unfortunately it flies in the face of agile methods which suggest that you write code as soon as possible. While I’m a fan of what agile methods strive to achieve, generally I see more cons than pros in practice.
Just to confuse myself, I’m about to completely contradict myself. Here’s why you should write code early, and it has nothing to do with the quality of experience of the resulting product, it’s about everything else. What else is there? There’s your team and getting them to work together, getting them up to speed on the problem domain you’re working in. There’s the technical bits like setting up source code control, issue trackers, development and qa servers. There’s the actual act of building and deploying a piece of working software.
All these are non-trivial bits that have very little to do with the quality of the experience the software delivers. You can deliver on all these and still end up with useless products. They are, however, real reasons why you want to deliver working software as early in the process as possible. To be honest, what you deliver in these early stages is almost irrelevant. It’s about getting the team and tools in place and working together. Think of it as training camp in sports.
Now for the contradiction. Writing code as a means of design is an expensive way to design poor software. It’s a great way to build a development team but clearly there’s a required balance here. Software is about the only industry that prototypes almost immediately. Look at architecture and automobiles as an example (Before we take this too far, I’m not suggesting we simply copy those industries). In both those more mature fields, they involve lengthy design phases prior to prototyping. As Bill mentioned in his recent talk, every automobile built today first had a full scale clay model rendered at costs of upwards of $250,000. The key being that they don’t get the clay out on day one. They spend months researching and designing long before they move to the prototype.
This isn’t a power play. This isn’t about removing software developers from the design process. This isn’t about no longer allowing the software construction process to inform and influence design. This is about building software that delivers a better and more relevant experience to the end user. This is about respecting and making effective use of one of your most valuable ‘tools’, your software development team. Yes, I just called myself a tool.
