Writing software is hard, but for a programmer, marketing it is even harder.
Once you've written the functionality, gussied up the interface, prepared the documentation and created the related webpages it is extremely frustrating to find that in actual fact, all you've done is managed to finish the easy stuff.
With 6 billion people in the world, you would think that getting some of them to look at and use your software would be straight forward.
The trick to selling software is surprisingly easy to state: All you have to do is create software that performs a task, find a group of people who need that task performed, create a moment of clarity for them regarding the purpose of the software and then find some way to stop them from crushing you in the rush to purchase.
The problem comes at the point you try to get the people who need the software to notice you, and to listen to you long enough for you to convey that moment of clarity.
The name of the game is Persistence.
Good Luck :)
Tuesday, September 9, 2008
Saturday, September 6, 2008
The iPhone, Legacy software and modern computer security
The problem with most common security models is that they are based on a security model that was developed many years ago for mainframe computer systems in an environment where, in general, the user was the distrusted element and not the process.
The user based security model that Unix and Windows offer today is actually nearly useless in the face of the real threat.
Traditionally in large mainframe systems it was the user that was seen as the threat, everything on the system was backed up on a regular basis and software in general did not tend to travel far enough, fast enough, to be much of a vector.
Because the user was seen as the potential source of trouble, they were given 'sandbox' environments known as 'user accounts' in which they could roam freely but not easily leave without demonstrating that they had the right to access other parts of the system.
On a modern PC, we all have documents, pictures and other personal files that we do not want to lose in the case of a problem, yet very few people outside of the IT community actually have backup systems in place, and nearly everyone stores those documents and files within their own user profile - the same user profile within which they run software they download from the internet, mount drives other people give them and generally take insane risks on.
The threat in this modern age is from the process and not the user. With password protected access the user can be assumed to be trusted to a reasonable extent, burglary victims aside, whereas a lot of software cannot.
A seemingly obvious solution to this is to place each application within its own 'user' space, treating them in the same way as Linux, Mac OS X and Vista currently treat individual users, with their own limited file access.
...and the iPhone does exactly this. Each individual iPhone application is limited to its own set own of folders, and has no ability to look outside them or to open or alter documents in other areas of the file system.
There is a single shared area, where the user can choose to place files for which that makes sense, but fundamentally each application is being given its own user space in exactly the same way that users are on other operating systems.
It is an interesting step forward, and one that I do expect to see appear on mac os x. The most likely initial implementation is as a 'sandbox' environment in which untrusted applications are run by default, with the user having the ability to move them outside of that environment once they are happy.
The user based security model that Unix and Windows offer today is actually nearly useless in the face of the real threat.
Traditionally in large mainframe systems it was the user that was seen as the threat, everything on the system was backed up on a regular basis and software in general did not tend to travel far enough, fast enough, to be much of a vector.
Because the user was seen as the potential source of trouble, they were given 'sandbox' environments known as 'user accounts' in which they could roam freely but not easily leave without demonstrating that they had the right to access other parts of the system.
On a modern PC, we all have documents, pictures and other personal files that we do not want to lose in the case of a problem, yet very few people outside of the IT community actually have backup systems in place, and nearly everyone stores those documents and files within their own user profile - the same user profile within which they run software they download from the internet, mount drives other people give them and generally take insane risks on.
The threat in this modern age is from the process and not the user. With password protected access the user can be assumed to be trusted to a reasonable extent, burglary victims aside, whereas a lot of software cannot.
A seemingly obvious solution to this is to place each application within its own 'user' space, treating them in the same way as Linux, Mac OS X and Vista currently treat individual users, with their own limited file access.
...and the iPhone does exactly this. Each individual iPhone application is limited to its own set own of folders, and has no ability to look outside them or to open or alter documents in other areas of the file system.
There is a single shared area, where the user can choose to place files for which that makes sense, but fundamentally each application is being given its own user space in exactly the same way that users are on other operating systems.
It is an interesting step forward, and one that I do expect to see appear on mac os x. The most likely initial implementation is as a 'sandbox' environment in which untrusted applications are run by default, with the user having the ability to move them outside of that environment once they are happy.
Tuesday, August 26, 2008
Clarity and Context
When developing an interface (or writing code for that matter) the best interfaces make each decision required by the user to be the outcome of a moment of clarity and context.
The user needs to know where they are, what they are doing there and what they are attempting to achieve at that moment.
This tends to be harder than it sounds.
Context and clarity is not often achieved by providing the user with more and more information, in fact the more information you attempt to give the user the less they are likely to understand (or even read) any of it.
Programmers tend to be aware of a lot of underlying context that almost certainly does not need to be known by the user unless they specifically request it. This can make it very hard to convince programmers to take away options and remove information simply because *programmers will think that the information they are removing is important*.
Clarity and context is achieved by stripping away absolutely everything that can be stripped away, and then presenting that which means in as clear a manner as possible, providing as much related information as possible and then indicating the most likely decision under the circumstances.
...this represents a fantastic contradiction, which tends to explain some of the grotesquely ugly interfaces that exist today...
The mechanism I find most helpful is to add everything that *could* be there, and then strip away everything that *shouldn't*, and finally to put back..often in small text and corners...information that might be helpful to them when they are making a decision.
but the real secret, when in doubt, take it away.
The user needs to know where they are, what they are doing there and what they are attempting to achieve at that moment.
This tends to be harder than it sounds.
Context and clarity is not often achieved by providing the user with more and more information, in fact the more information you attempt to give the user the less they are likely to understand (or even read) any of it.
Programmers tend to be aware of a lot of underlying context that almost certainly does not need to be known by the user unless they specifically request it. This can make it very hard to convince programmers to take away options and remove information simply because *programmers will think that the information they are removing is important*.
Clarity and context is achieved by stripping away absolutely everything that can be stripped away, and then presenting that which means in as clear a manner as possible, providing as much related information as possible and then indicating the most likely decision under the circumstances.
...this represents a fantastic contradiction, which tends to explain some of the grotesquely ugly interfaces that exist today...
The mechanism I find most helpful is to add everything that *could* be there, and then strip away everything that *shouldn't*, and finally to put back..often in small text and corners...information that might be helpful to them when they are making a decision.
but the real secret, when in doubt, take it away.
Sunday, August 24, 2008
The Trials and Tribulations of a Software Developer
There are an almost insane number of factors that a computer programmer must consider as a part of their day.
A 'simple' web developer utilising mysql, php, javascript, css and html. is moving between *5* different syntaxes on a minute to minute basis, the typical development target for web development these days is IE 6, IE 7, and the most recent versions of Safari and Firefox/Mozilla.
That is effectively 5 languages (for some definition of the word) focusing on 4 noticeably different platforms, with different quirks and tricks.
at the same time the programer must be aware of the layout and design of the database, the layout, design and future goals of the code base, the possible ramifications of the changes they are making on those goals, on the existing codebase.
Also they must consider the security ramifications of the decisions they are making as they go,
They are usually working with code written at least in part by other developers in the organisation with skill levels that vary, they will frequently be working with third party libraries and API that vary in quality and ease of use and they often have to deal with features that must be implemented on short notice or with limited initial research time available.
When they actually write code they must keep in their heads the design goals of the specific problem they are trying to solve, the best way of fitting those goals into the overall design goals and methods of the larger codebase and the limits on the resources that they have available in terms of browser CPU usage, bandwidth, database access times - *and* they have to have formed an opinion on the best way of solving the problem within those limitations.
and..especially with web design...the result must look good.
Being a good developer is about achieving Context and Clarity at each step of the process, concentration focused on the goal, but maintaining awareness of the complexity that surrounds them, allowing it to guide, without letting it distract them.
With all this to consider it is, quite frankly, astonishing that they can bring themselves to take the risk of writing any code at all.
A 'simple' web developer utilising mysql, php, javascript, css and html. is moving between *5* different syntaxes on a minute to minute basis, the typical development target for web development these days is IE 6, IE 7, and the most recent versions of Safari and Firefox/Mozilla.
That is effectively 5 languages (for some definition of the word) focusing on 4 noticeably different platforms, with different quirks and tricks.
at the same time the programer must be aware of the layout and design of the database, the layout, design and future goals of the code base, the possible ramifications of the changes they are making on those goals, on the existing codebase.
Also they must consider the security ramifications of the decisions they are making as they go,
They are usually working with code written at least in part by other developers in the organisation with skill levels that vary, they will frequently be working with third party libraries and API that vary in quality and ease of use and they often have to deal with features that must be implemented on short notice or with limited initial research time available.
When they actually write code they must keep in their heads the design goals of the specific problem they are trying to solve, the best way of fitting those goals into the overall design goals and methods of the larger codebase and the limits on the resources that they have available in terms of browser CPU usage, bandwidth, database access times - *and* they have to have formed an opinion on the best way of solving the problem within those limitations.
and..especially with web design...the result must look good.
Being a good developer is about achieving Context and Clarity at each step of the process, concentration focused on the goal, but maintaining awareness of the complexity that surrounds them, allowing it to guide, without letting it distract them.
With all this to consider it is, quite frankly, astonishing that they can bring themselves to take the risk of writing any code at all.
Visual Task Management
So I am a great fan of using task lists and to do lists, but have often found myself a little frustrated with my inability to group tasks visually, move them around the screen, collapse them together, file them away and generally treat them like pieces of paper.
this is an alpha version of a combination todo list and task management application that is designed to let tasks be grouped visually, filed away for future reference, moved from one task to another, become projects themselves and so forth.
Basically I am aiming for a very flexible way of pushing tasks around, and this lets me do most of that, I am interested in what people think and whether you find it generally useful.
it is written in fairly OO php 5, and uses the prototype javascript library pretty heavily for the ajax stuff.
SharpDo
its a little slow, btw. this is caused entirely by the fact it is run on a godaddy server.
this is an alpha version of a combination todo list and task management application that is designed to let tasks be grouped visually, filed away for future reference, moved from one task to another, become projects themselves and so forth.
Basically I am aiming for a very flexible way of pushing tasks around, and this lets me do most of that, I am interested in what people think and whether you find it generally useful.
it is written in fairly OO php 5, and uses the prototype javascript library pretty heavily for the ajax stuff.
SharpDo
its a little slow, btw. this is caused entirely by the fact it is run on a godaddy server.
Saturday, August 16, 2008
Science - a game of belief the whole family can play
The basis of science is a simple game that anyone in your family can play.
it goes like this: take any simple observation and ask yourself 'if God didn't do this, what did?'
The idea is not to deny the existence of God. Science has nothing useful or intelligent to say on that subject.
The idea is to seek simple explanations for simple observations of natural phenomena and to use the solutions to improve our lives.
The Game of Science has brought us tampons, computers, microwaves and flushable toilets. It is a fun game.
Teach it to your children.
it goes like this: take any simple observation and ask yourself 'if God didn't do this, what did?'
The idea is not to deny the existence of God. Science has nothing useful or intelligent to say on that subject.
The idea is to seek simple explanations for simple observations of natural phenomena and to use the solutions to improve our lives.
The Game of Science has brought us tampons, computers, microwaves and flushable toilets. It is a fun game.
Teach it to your children.
Friday, November 9, 2007
Infinitely Malleable Software (Could it?....yes, it could)
It seems to be almost a dirty secret in software development, it is certainly not something Ive seen discussed much, software is for most intents and purposes, infinitely malleable.
When a client asks 'could we make it do', the answer, ultimately, is 'yes, we could'.
This is the ultimate problem with software, and I could easily argue that this is one of the main reasons that many software projects fail...the secret to releasing software successfully is choosing very carefully which of the infinite possible features available are right for the specific computer program at hand.
This is the reason that good ideas are easy to think of, but successful and popular implementations of any specific one are much harder to find.
Zawinski’s Law states:
"Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can."
My argument is, of course, that there is no software solution that cannot, at a pinch, so expand.
This is why it is vitally important that you personally resist the temptation.
When a client asks 'could we make it do
This is the ultimate problem with software, and I could easily argue that this is one of the main reasons that many software projects fail...the secret to releasing software successfully is choosing very carefully which of the infinite possible features available are right for the specific computer program at hand.
This is the reason that good ideas are easy to think of, but successful and popular implementations of any specific one are much harder to find.
Zawinski’s Law states:
"Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can."
My argument is, of course, that there is no software solution that cannot, at a pinch, so expand.
This is why it is vitally important that you personally resist the temptation.
Solving Software Tasks (Or, How To Install Booster Seats)
It is only by attempting a task in the first instance that we can learn what is truly required to complete it.
My preferred approach in such a situation, one where both skill and knowledge are required, is to begin by attempting to complete the task without reading the instructions.
At first glance this might appear foolish, but experience has taught me that the instructions tend to mean very little until I have some context to place them in.
A series of pictures has no semantic content if I go straight to that, in order to understand the pictures I first need to...for want of a better phrase...play with the pieces.
In the case of the booster seats this means picking one up, glancing at it, dropping it into the back seat and attempting to arrange the seatbelt around it in the most obvious way possible.
Having done this, I quickly decided that my naive attempt was unsuccessful...there was clearly too much slack and movement in the seat for it to be safe.
For my second attempt I took a more thoughtful approach and tried to thread the seatbelt through some provided handles at the back...again, once completed, it was painfully obvious that the seat was too loosely held to be safe.
Having decided this I could now go back to the instructions and reread them...this time things have changed however, this time I have some idea of the problems that the instructions are attempting to solve and a decent grasp of the tools that are available and the different ways they can be used together.
This time, I have experience.
Things were easier years ago when most men, as most men should, tended to be both more confident and more skilled with their hands, they could casually throw together a wooden deck, or tell at a glance the best technique for installing wall fittings and roof mounted television aerials.
Why am I unable to 'grok' the instructions before I have explored the context they are based on?
The stereotypical tendency of men to disregard instructions early on in the process is not, as is usually claimed, because their ego requires them to do so. It is because the instructions themselves carry very little semantic content until their context has been explored and understood.
The time spent exploring and understanding the context by 'playing with the pieces' is not a waste, it is a necessary step to ensure that the instructions themselves are not merely followed, but are fully understood and that when I do come to follow them, I can do so with a deeper understanding of the parts involved and their relative strengths and abilities.
For me this process maps directly to software development, I am a firm believer in designing by doing. The actual ability of libraries, frameworks and other third party code to solve the problems you want solved is an unproven quality until it has been done, and if the third party code is going to fail it is important that this fact be discovered as early as possible in the design process.
The same can be said of the design itself, until it has been brought together.
My preferred approach in such a situation, one where both skill and knowledge are required, is to begin by attempting to complete the task without reading the instructions.
At first glance this might appear foolish, but experience has taught me that the instructions tend to mean very little until I have some context to place them in.
A series of pictures has no semantic content if I go straight to that, in order to understand the pictures I first need to...for want of a better phrase...play with the pieces.
In the case of the booster seats this means picking one up, glancing at it, dropping it into the back seat and attempting to arrange the seatbelt around it in the most obvious way possible.
Having done this, I quickly decided that my naive attempt was unsuccessful...there was clearly too much slack and movement in the seat for it to be safe.
For my second attempt I took a more thoughtful approach and tried to thread the seatbelt through some provided handles at the back...again, once completed, it was painfully obvious that the seat was too loosely held to be safe.
Having decided this I could now go back to the instructions and reread them...this time things have changed however, this time I have some idea of the problems that the instructions are attempting to solve and a decent grasp of the tools that are available and the different ways they can be used together.
This time, I have experience.
Things were easier years ago when most men, as most men should, tended to be both more confident and more skilled with their hands, they could casually throw together a wooden deck, or tell at a glance the best technique for installing wall fittings and roof mounted television aerials.
Why am I unable to 'grok' the instructions before I have explored the context they are based on?
The stereotypical tendency of men to disregard instructions early on in the process is not, as is usually claimed, because their ego requires them to do so. It is because the instructions themselves carry very little semantic content until their context has been explored and understood.
The time spent exploring and understanding the context by 'playing with the pieces' is not a waste, it is a necessary step to ensure that the instructions themselves are not merely followed, but are fully understood and that when I do come to follow them, I can do so with a deeper understanding of the parts involved and their relative strengths and abilities.
For me this process maps directly to software development, I am a firm believer in designing by doing. The actual ability of libraries, frameworks and other third party code to solve the problems you want solved is an unproven quality until it has been done, and if the third party code is going to fail it is important that this fact be discovered as early as possible in the design process.
The same can be said of the design itself, until it has been brought together.
Wednesday, March 14, 2007
Getting Things Done (or Tracking Your Time)
I waste a _lot_ of time on my computer.
Its true, sometimes its because Im too tired to enter a decent working state, and too stupid to leave the computer and just walk away.
God night.
Its true, sometimes its because Im too tired to enter a decent working state, and too stupid to leave the computer and just walk away.
God night.
Subscribe to:
Posts (Atom)