Archive for July, 2006

Learning from my own mistakes

I was looking for a hosting provider for yourclients.co.uk and I decided to go with UK based namesco.co.uk.

Everything was fine for the first 10 minutes - they do both PHP4 and PHP5, and MySQL5.

Sounds good, doesn’t it?

After signing up for the account and receiving my details I run phpinfo(); and it states: PHP4.4.1

What?

Where’s my PHP5?

After a quick email to support@ I received an answer that to run PHP5 scripts the files need to have .php5 extensions.

That’s obviously rubbish and I need to find another host…

Or do I?

My system will run off the main index.php acting as a PageController, so effectively no other files will be “ran”.

What I should be able to do is to rename my index.php to index.php5 and… That’s it!

I hope that works, but I don’t see a reason it shouldn’t, after all when the file is executed it already knows which version of the interpreter to use.

So - 1:0 for me, my system will work even on not-optimal hosting configurations :-D

Comments

Pre-launch publicity

I discovered recently, that one of the biggest factors making consumer software projects unsuccessful is the lack of publicity in the early days.

What’s your software worth, if noone knows about it?

I also think, that “ideas are cheap, execution is expensive”, so I won’t keep my idea in secret.

It isn’t very original, the market is existent for a long time, but still the amount of companies that use such software is very limited.

The potential problem is educating these companies that they NEED my solution, and that it helps, not hinders their organisation, but that can also be achieved through hard work.

So there we go - the idea is - Web-based Help Desk software, integrated with your website.

At this stage all I have is the domain name (yourclients.co.uk, what do you think?)and a PHP5 application framework, so there isn’t any specific domain logic embedded into it yet - and as I start from scratch I have a decent chance of making this solution “different”, and hopefully “remarkable”, so people would feel inclined to actually make a remark about it.

I’ll have to mock up a placeholder page on that domain name now so it’s indexed in Google and other search engines, so when launched it will actually have “linkpower”.

The other thing is payment processing, I think I’ll have to go with PayPal at this stage until things are more established in terms of cashflow.

Yeah, wish me luck :)

Comments

Sometimes too flexible is too complex

For your next revolution, try not to follow the pattern of Microsoft’s DataGrid/GridView control.

It’s a wonderful thing, once you know how to use it.

I saw an 12-page article on that, and even a dedicated website!

Considering, that this control was supposed to “make displaying tabular data easier” it definitively didn’t flatten the learning curve, the API is impossible to use without first reading a comprehensive guide about it.

Yes, I agree, this is a powerful tool, and useful - I use it every other day - but most of the features seems simply obsolete, and the abstraction level offered seems… to abstract ;)

I’m not a huge fan of writing everything from scratch, but sometimes it really IS quicker to hack few bits together than reuse component which is intimidating in first approach.

I find myself an advocate of HumaneInterfaces, what means - writing your components to be usable by people, not machines ;)

For instance I love Ruby’s construct:

5.times do
//something
end

This is far less intimidating than PHP’s:

for ($a=0; $asimple!

The times of coding for the Implementation are long gone, now you can focus on coding for the People.

Comments

The revolutionaries’ problem

I discovered recently one of the biggest problems all revolutionaries face - the lack of understanding of their brilliance.

This is a very simple thing in one way - others simply “don’t get it”, being used to doing things the “old way”.

The “old way” usually means a way they know every aspect of, like, know what to expect from it and more importantly - feel comfortable with.

I can imagine nay-sayers deprecating every major breakthrough we had, starting with the telephone (”you have to lay wires to every town, state and country - a monstrous job!”), or a train (”the vacuum from outside the carriage will suffocate the passengers”) to more modern ones - like the internet (”it’s only for watching porn and downloading device drivers, what else do you need it for?”).

But as always, the adoption curve comes kicks in and more and more people start using such a service/idea/methodology.

What seems to be needed for advocating “new ways” is to cross the chasm, but it still happens on a “user by user” basis, very rarely it comes as a sudden revolution (revolutions like AJAX/web2.0 being the good exceptions of that rule).

But if you don’t have the huge marketing machine (buzz generator) behind you, how do you get your point across?

The best thing to do, at least in IT-related fields seems to be creating a comprehensive comparison of the “old” and “new” ways, in a strongly graphical way, accompanies by easy-to-grasp charts, code snippets, and most importantly - pros and cons of each solution.

Don’t think your revolutionary idea is “needed” by anyone - they got without it until Today, so they can live perfectly well without it - so try to communicate the “real, hard advantages” instead of “paradigm-shifting, first-mover advantage generating solution”.

But sometimes it doesn’t help, the technology has to wait until its time comes, until people start to realize that they HAVE a problem and they want to do something about it and seek solutions to it.

This is where it seems easiest to help them by offering your “new approach”.

But by the time it comes - is it still a “revolution”, or merely an “evolution”? This is argueable.

But the rule seems to be - try to help people which are looking for and open to New Ways (in other words - acknowledge that they have a PROBLEM), you’ll get a very big barrier out of the way.

Don’t be a solution waiting for the right problem.

Comments

Quote of the day

“You know, we have a feeling when programming as well”

Comments

Estimation pitfalls

We live in a society using Gregorian Calendar - what that means is we are used to months having “around 30 days”, and weeks having “always 7 days”.

This knowledge is very useful for estimating the amount of time until someone’s birthday, it just “feels” like a short/long time when you hear the number - your gut insticts tells you “it’s soon, it’s time to buy a present”, or “you have plenty of time to sort this out, don’t worry”.

While we live for some time we get used to this “abundance” of time to sort things out - two weeks is more than enough for almost everything (except buing a house ;) , but the problem begins when you try to apply this “common sense knowledge” to software estimation.

The working week - has only 5 days, and month - usually 21 days.

That is much much less than you “feel” it has!

If you’d estimate something will take “a full week”, which is 7 days, your client/boss will hear “5 days”, which already is 40% longer (7/5 = 140%)!

The same goes for the month, you think “a month, about 30 days” and he hears “21 days”, which is 42% underestimated for the same amount of “time”.

Add to that the slack caused by “getting into the zone” on Monday morning and picking up the stuff you left somewhere on Friday - and you’ll start to feel even more time slips through your fingers.

That might explain why the plumbers charge 40 pounds per hour - it seems like they can earn more than bank directors, but not so when you take into account all the inefficiencies in getting to you (physically) and getting to you (advertising efforts).

That also explains why every project takes a horribly long time - because we have a life outside work :-)

The point is - when doing estimates, use HOURS instead of DAYS as the “Unit of work”.

And don’t assume you’ll work effectively on Friday evenings ;)

Comments

…But why software?

You might think that buying a computer might guarantee you “the experience”, after all - you have all the nuts and bolts under the bonnet, the IT-horsepower that everyone claims to be so powerful.

But a computer itself is indeed just like a car - you have to buy a World for him to drive in. The world itself determines what you can do in your car, where you can get, how fast, its parameters define your speed, range and comfort of your ride.

And sometimes, these worlds simply don’t have everything you dream about - like a Loop of Death or 5-lane motorway with no speed limit.

What’s the point of having a modern car if you can’t use it in the ways you like?

That’s exactly the role of software in Today’s world - to enable us to do things quicker, smarter and provide us with a level of automation of mundane everyday’s tasks.

But do you really need a custom built software?

Not always.

Sometimes it’s enough to have your typical Windows XP machine with Office XP installed and you don’t need much more to do what you have to do - all of these machines have the web browser included which allows them to use the biggest network in the world.

But that biggest network is also a separate world in a sense - and web software gives him a shape. This world seems to gradually take over other worlds, abstracting physical operations and giving them abstract, digital form.

Do you remember your last visit to your bank? I bet you know your last 3 operations on your account though.

Developing software then - is a good opportunity to unleash the creativity in order to make people’s lifes easier and more enjoyable.

It is an art.

Without which we wouldn’t be able to live anymore, being used to our standard of living.

I’m currently in the phase of looking for interesting problems to solve, or new products to develop, so if you have any problems that need tackling - just give me a shout ;)

Comments

When excessive complexity is not excessive

I had an interesting assignment recently, having received a multi-dimensional PHP array (about 4 levels deep) and was supposed to enable editing it - so what might seem obvious is starting like:

I decided to come up with an Object model for it looking like:

And I also created some other classes, representing the sub-nodes of the original data.

But what is most important in that kind of approach:

  • When the original structure changes - I only need to modify the getters/setters in my Object Model!
  • The code is clean and readable, as $element->getName() is much easier to comprehend than $array[”elements”][0][”element”],
  • The rest of your code doesn’t care about the data structure,
  • The OO flexibility allows you to abstract the “data” handling to be compatible with other data sources, e.g. XML files or relational databases,
  • You avoid “offset errors”, when you try to do calculations on a node which comes from different level of the array than you expect it to,
  • No repetition - you define only once “what comes from where”, later on you just user your definitions,

Of course the above sample also needs proper “usage” abstraction, which basically means objects are used according to the business rules, not the “byte manipulation”, e.g.

setFrom($data);
$MainNode->getName();
$Addresses = $MainNode->getAllAddresses();
foreach ($Addresses as $address) {
$address->sendNotification();
}
// and we continue in this matter
?>

The key point of that is to make your code readable - when your method names are obvious you don’t really need many comments in the code - it all seems self-explanatory.

Of corse you should still document any unexpected behaviour and quick hacks - but it’s better not to introduce them in the first place.

Comments