Monday, November 24, 2008

EDSK ... they will benefit from a breadth of experiences

"The ideal engineer is a composite … he is not a scientist, he is not a mathematician, he is not a sociologist, or a writer; but he may use the knowledge and techniques of any or all of these disciplines in solving engineering problems."
—N. W. Dougherty

Tuesday, November 18, 2008

The duality of programming languages that are easy to learn

Or. The duality of easy adoption.

I'm calling out programming languages here but it applies to other things also.

If a programming language is easy to learn, lots of people will use it.
Lots of people, with no formal training or idea about best practices or the consequences of the coding decisions they make (because they don't need it - as the language is easy to use) leads to lots of bad code.
However, if code wasn't easy to write, fewer programmes would be written and we wouldn't experience the benefits of those programs.
If code was harder to write, it would (arguably) be better code (due to the need to understand what you  are doing and why) but there would be less of it.


The challenge:
1. Make sure that you know best practices and the consequences of using one technique over another.
2. Pass on that knowledge to others.

Saturday, November 15, 2008

Indicators that a company will provide poor customer service

Found this list, I made earlier in the year, prompted by spending a day talking to companies at exhibition stands at a conference.

No collateral
If they haven't got anything you can take away to remind you about a product, it shows that you aren't doing everything you can to make it easy for me, a potential customer. Why should I think that you treat actual customers any better?

No info on website homepage
So I haven't got anything tangible to remind me of, or provide details about, you or your product.  If that information isn't on your website how am I supposed to learn anything about the product, in my own time, and at my own pace.  Again, you're not making it easy for me.

Poor/no documentation/user guides/ etc.

If you haven't got anything to help users help themselves, why should I think you've got any resources that you can use to help? And if you have, why keep them to yourself?

You have to give them your information to get anything out of them (info/samples/docs/tools)
If you're more interested in getting my contact details than telling me about your product, why would I think that you're interested in anything other than I money, such as providing support if I became a customer?

No published prices
Why are you not publishing your prices? Unless it's because you desperately want my contact details rather than let me determine if your product/service/etc. is in my price range?  Or am I going to see the price and not think it's appropriate unless one of your sales people explains to me why it's not overpriced.  So, why aren't you spending your time making a great product that I can use, understand and see the benefits of?

No support SLA or escalation detailsYou haven't thought how you're going to be able to deal with the issues or questions I may have? and ensure that I get appropriate resolutions in a timely manner?

What's stopping you presenting?

It's like Dr Pepper said ...

But, most people want it/you to be good and go in with that expectation.
I'm pretty sure, psychologically, that means they'll think it better that it was/is anyway.

My Presentation at DevEvening #5

The 14th of November saw my first presentation at DevEvening and it went down pretty well.

I presented on the topic of "What you 'really' need to know about developing for Windows Mobile."
It was my attempt at a 30 minute crash course introduction to developing for Windows Mobile and some key things you should know when you do.

In part it was a response to the idea that if you can develop for the desktop, you can develop for Windows Mobile.

I talked about:
  • Developing for Windows Mobile is not like developing for the desktop:
    • Aim for maximum responsiveness on a mobile device. - Users have higher expectations.
    • Design for occassional connectedness. -You could lose connection at any point.
    • Do as little as possible. - You have limited resources and everything eats battery life, which is precious!
  • Developing for one device is not, necessarily, the same as developing for another:
    • Different size screens
    • More and different methods of input - Make things big enough to touch with a finger.

Slides:


I used a few, very simple demos.  The code was so trivial I'm not posting it here, but if you're interested, drop me a line and I'll hook you up.