As a "user" of Amazon's Web Services (I've kicked the tyres on S3, but not much more than that) I received an email from Amazon punting their new DNS service, dubbed "Amazon Route 53".
I wonder though, in the wake of their termination of WikiLeaks, whether I would trust any part of my DNS infrastructure to Amazon. Suppose I did something to piss off the US governement - hosted a DNS entry for WikiLeaks, perhaps? at, say, http://wikileaks.mikro2nd.net/ - and some US government official notices (pretty unlikely, I know, but...) and whispers into Amazon's ear, would I, too, lose use of this critical infrastructure without review, recourse or refund?
So, no! I don't think I'll be using Amazon Route 53 much...
07 December 2010
18 October 2010
HTTP Response codes & msgs as Java enum
Just in case it saves someone else the tedious typing... Capitalisation of messages duplicates the inconsistencies in RFC2616. Don't ask me...
public enum HttpResponse {
HTTP_100( 100, "HTTP/1.0 100 Continue\r\n\r\n" ),
HTTP_101( 101, "HTTP/1.0 101 Switching Protocols\r\n\r\n" ),
HTTP_200( 200, "HTTP/1.0 200 OK\r\n\r\n" ),
HTTP_201( 201, "HTTP/1.0 201 Created\r\n\r\n" ),
HTTP_202( 202, "HTTP/1.0 202 Accepted\r\n\r\n" ),
HTTP_203( 203, "HTTP/1.0 203 Non-Authoritative Information\r\n\r\n" ),
HTTP_204( 204, "HTTP/1.0 204 No Content\r\n\r\n" ),
HTTP_205( 205, "HTTP/1.0 205 Reset Content\r\n\r\n" ),
HTTP_206( 206, "HTTP/1.0 206 Partial Content\r\n\r\n" ),
HTTP_300( 300, "HTTP/1.0 300 Multiple Choices\r\n\r\n" ),
HTTP_301( 301, "HTTP/1.0 301 Moved Permanently\r\n\r\n" ),
HTTP_302( 302, "HTTP/1.0 302 Found\r\n\r\n" ),
HTTP_303( 303, "HTTP/1.0 303 See Other\r\n\r\n" ),
HTTP_304( 304, "HTTP/1.0 304 Not Modified\r\n\r\n" ),
HTTP_305( 305, "HTTP/1.0 305 Use Proxy\r\n\r\n" ),
HTTP_307( 307, "HTTP/1.0 307 Temporary Redirect\r\n\r\n" ),
HTTP_400( 400, "HTTP/1.0 400 Bad Request\r\n\r\n" ),
HTTP_401( 401, "HTTP/1.0 401 Unauthorized\r\n\r\n" ),
HTTP_402( 402, "HTTP/1.0 402 Payment Required\r\n\r\n" ),
HTTP_403( 403, "HTTP/1.0 403 Forbidden\r\n\r\n" ),
HTTP_404( 404, "HTTP/1.0 404 Not Found\r\n\r\n" ),
HTTP_405( 405, "HTTP/1.0 405 Method Not Allowed\r\n\r\n" ),
HTTP_406( 406, "HTTP/1.0 406 Not Acceptable\r\n\r\n" ),
HTTP_407( 407, "HTTP/1.0 407 Proxy Authentication Required\r\n\r\n" ),
HTTP_408( 408, "HTTP/1.0 408 Request Time-out\r\n\r\n" ),
HTTP_409( 409, "HTTP/1.0 409 Conflict\r\n\r\n" ),
HTTP_410( 410, "HTTP/1.0 410 Gone\r\n\r\n" ),
HTTP_411( 411, "HTTP/1.0 411 Length Required\r\n\r\n" ),
HTTP_412( 412, "HTTP/1.0 412 Precondition Failed\r\n\r\n" ),
HTTP_413( 413, "HTTP/1.0 413 Request Entity Too Large\r\n\r\n" ),
HTTP_414( 414, "HTTP/1.0 414 Request-URI Too Large\r\n\r\n" ),
HTTP_415( 415, "HTTP/1.0 415 Unsupported Media Type\r\n\r\n" ),
HTTP_416( 416, "HTTP/1.0 416 Requested range not satisfiable\r\n\r\n" ),
HTTP_417( 417, "HTTP/1.0 417 Expectation Failed\r\n\r\n" ),
HTTP_500( 500, "HTTP/1.0 500 Internal Server Error\r\n\r\n" ),
HTTP_501( 501, "HTTP/1.0 501 Not Implemented\r\n\r\n" ),
HTTP_502( 502, "HTTP/1.0 502 Bad Gateway\r\n\r\n" ),
HTTP_503( 503, "HTTP/1.0 503 Service Unavailable\r\n\r\n" ),
HTTP_504( 504, "HTTP/1.0 504 Gateway Time-out\r\n\r\n" ),
HTTP_505( 505, "HTTP/1.0 505 HTTP Version not supported\r\n\r\n" );
private final int intValue;
private final String msg;
private HttpResponse( int intValue, final String msg ){
this.intValue = intValue;
this.msg = msg;
}
public int intValue(){
return intValue;
}
public String responseString(){
return msg;
}
public static HttpResponse forResponseCode( int responseCode ){
for( HttpResponse v : values() ){
if( responseCode == v.intValue() ) return v;
}
throw new IllegalArgumentException();
}
}
public enum HttpResponse {
HTTP_100( 100, "HTTP/1.0 100 Continue\r\n\r\n" ),
HTTP_101( 101, "HTTP/1.0 101 Switching Protocols\r\n\r\n" ),
HTTP_200( 200, "HTTP/1.0 200 OK\r\n\r\n" ),
HTTP_201( 201, "HTTP/1.0 201 Created\r\n\r\n" ),
HTTP_202( 202, "HTTP/1.0 202 Accepted\r\n\r\n" ),
HTTP_203( 203, "HTTP/1.0 203 Non-Authoritative Information\r\n\r\n" ),
HTTP_204( 204, "HTTP/1.0 204 No Content\r\n\r\n" ),
HTTP_205( 205, "HTTP/1.0 205 Reset Content\r\n\r\n" ),
HTTP_206( 206, "HTTP/1.0 206 Partial Content\r\n\r\n" ),
HTTP_300( 300, "HTTP/1.0 300 Multiple Choices\r\n\r\n" ),
HTTP_301( 301, "HTTP/1.0 301 Moved Permanently\r\n\r\n" ),
HTTP_302( 302, "HTTP/1.0 302 Found\r\n\r\n" ),
HTTP_303( 303, "HTTP/1.0 303 See Other\r\n\r\n" ),
HTTP_304( 304, "HTTP/1.0 304 Not Modified\r\n\r\n" ),
HTTP_305( 305, "HTTP/1.0 305 Use Proxy\r\n\r\n" ),
HTTP_307( 307, "HTTP/1.0 307 Temporary Redirect\r\n\r\n" ),
HTTP_400( 400, "HTTP/1.0 400 Bad Request\r\n\r\n" ),
HTTP_401( 401, "HTTP/1.0 401 Unauthorized\r\n\r\n" ),
HTTP_402( 402, "HTTP/1.0 402 Payment Required\r\n\r\n" ),
HTTP_403( 403, "HTTP/1.0 403 Forbidden\r\n\r\n" ),
HTTP_404( 404, "HTTP/1.0 404 Not Found\r\n\r\n" ),
HTTP_405( 405, "HTTP/1.0 405 Method Not Allowed\r\n\r\n" ),
HTTP_406( 406, "HTTP/1.0 406 Not Acceptable\r\n\r\n" ),
HTTP_407( 407, "HTTP/1.0 407 Proxy Authentication Required\r\n\r\n" ),
HTTP_408( 408, "HTTP/1.0 408 Request Time-out\r\n\r\n" ),
HTTP_409( 409, "HTTP/1.0 409 Conflict\r\n\r\n" ),
HTTP_410( 410, "HTTP/1.0 410 Gone\r\n\r\n" ),
HTTP_411( 411, "HTTP/1.0 411 Length Required\r\n\r\n" ),
HTTP_412( 412, "HTTP/1.0 412 Precondition Failed\r\n\r\n" ),
HTTP_413( 413, "HTTP/1.0 413 Request Entity Too Large\r\n\r\n" ),
HTTP_414( 414, "HTTP/1.0 414 Request-URI Too Large\r\n\r\n" ),
HTTP_415( 415, "HTTP/1.0 415 Unsupported Media Type\r\n\r\n" ),
HTTP_416( 416, "HTTP/1.0 416 Requested range not satisfiable\r\n\r\n" ),
HTTP_417( 417, "HTTP/1.0 417 Expectation Failed\r\n\r\n" ),
HTTP_500( 500, "HTTP/1.0 500 Internal Server Error\r\n\r\n" ),
HTTP_501( 501, "HTTP/1.0 501 Not Implemented\r\n\r\n" ),
HTTP_502( 502, "HTTP/1.0 502 Bad Gateway\r\n\r\n" ),
HTTP_503( 503, "HTTP/1.0 503 Service Unavailable\r\n\r\n" ),
HTTP_504( 504, "HTTP/1.0 504 Gateway Time-out\r\n\r\n" ),
HTTP_505( 505, "HTTP/1.0 505 HTTP Version not supported\r\n\r\n" );
private final int intValue;
private final String msg;
private HttpResponse( int intValue, final String msg ){
this.intValue = intValue;
this.msg = msg;
}
public int intValue(){
return intValue;
}
public String responseString(){
return msg;
}
public static HttpResponse forResponseCode( int responseCode ){
for( HttpResponse v : values() ){
if( responseCode == v.intValue() ) return v;
}
throw new IllegalArgumentException();
}
}
13 October 2010
A Lesson from Vegetable Gardening for Hiring (and Keeping) Better Software Developers
Right now I'm in the midst of Busy Season in the Veggie Garden: Spring Planting Time. Even busier than harvest time. You see, you can almost always delay a harvest by a few days or a week without serious consequences. But you can't delay sowing seed without reaping serious consequences 4 to 6 months down the line. Veggie gardening is all about strategy.
Just the other day I heard about a successful and growing Cape Town company planning a hiring spree for Java developers. They'll be looking for quite a number of Java developers at all skill and experience levels.
But they face two key problems:
This is great news for Java devs: Salaries are pretty competitive, even if not quite up to Jo'burg levels just yet.
Hell for employers, though.
Strategy is about Time
My main problem this Planting Season is that I don't have any compost for the garden. The key to making great compost is adding plenty of water, and the key to great veggie crops is building the soil by adding compost, year after year after year. But we're (still) in a drought, so no water. Successful crops are going to be a serious challenge this Summer...
CEOs, CTOs and Development Managers who get it know that investing in their developers' skills, knowledge and experience is investing in their own success and the success of their business. And the secret is that it can't be done overnight. It takes long-term commitment to helping their developers build their skills. And intelligent developers reward real, honest commitment to skills- and career-development with loyalty.
And developers talk to each other. In their mailing lists and user-group meetings, on Facebook and Twitter, word-of-mouth ensures that developers have a pretty good idea of who is doing the interesting software, who is providing a stimulating development environment. In short, who the good employers are. (Especially in Cape Town! The software world in CT really is a very small village.)
Compost making and soil-building is a strategic practise for farmers and gardeners everywhere, whether they are organic growers (like me) or not, soil-building is of vital strategic importance. Without healthy soil we have nothing.
Likewise, CEOs, CTOs and Dev Managers of companies for whom software development is a strategic business activity have a vital interest in developing their developers.
Planning to Hire Developers Any Time Soon?
If you are planning to attempt to hire developers (particularly Java developers; particularly in or around Cape Town) within the next 6 months, ask yourself the following 3 questions:
If you'd like help creating fertile ground for interesting minds who can help drive your software development to greater successes, call me.
Just the other day I heard about a successful and growing Cape Town company planning a hiring spree for Java developers. They'll be looking for quite a number of Java developers at all skill and experience levels.
But they face two key problems:
- There is an extreme scarcity of Java developers at any and all levels in Cape Town and surrounds.
- They'll be competing against a very large number of other employers looking for large numbers of Java developers. I have, over the past couple of months, heard of numerous companies searching for 10, 12 and more "skilled Java developers".
This is great news for Java devs: Salaries are pretty competitive, even if not quite up to Jo'burg levels just yet.
Hell for employers, though.
Strategy is about Time
My main problem this Planting Season is that I don't have any compost for the garden. The key to making great compost is adding plenty of water, and the key to great veggie crops is building the soil by adding compost, year after year after year. But we're (still) in a drought, so no water. Successful crops are going to be a serious challenge this Summer...
CEOs, CTOs and Development Managers who get it know that investing in their developers' skills, knowledge and experience is investing in their own success and the success of their business. And the secret is that it can't be done overnight. It takes long-term commitment to helping their developers build their skills. And intelligent developers reward real, honest commitment to skills- and career-development with loyalty.
And developers talk to each other. In their mailing lists and user-group meetings, on Facebook and Twitter, word-of-mouth ensures that developers have a pretty good idea of who is doing the interesting software, who is providing a stimulating development environment. In short, who the good employers are. (Especially in Cape Town! The software world in CT really is a very small village.)
Compost making and soil-building is a strategic practise for farmers and gardeners everywhere, whether they are organic growers (like me) or not, soil-building is of vital strategic importance. Without healthy soil we have nothing.
Likewise, CEOs, CTOs and Dev Managers of companies for whom software development is a strategic business activity have a vital interest in developing their developers.
Planning to Hire Developers Any Time Soon?
If you are planning to attempt to hire developers (particularly Java developers; particularly in or around Cape Town) within the next 6 months, ask yourself the following 3 questions:
- How are you going to source the best and brightest devs when they're almost unreachable at any price?
- How are you going to make your company more attractive to those devs than all the competition you face?
- How are you going to keep developers from job-hopping when they get that email from a competing employer or headhunter offering them a huge raise?
If you'd like help creating fertile ground for interesting minds who can help drive your software development to greater successes, call me.
05 October 2010
Duck Typing Developer Styles: 4 Ducks
Developers can be categorised along two orthogonal dimensions: coding-skills and design-skills. This post explains how to locate a developer according to this scheme, and describes how best to manage each development-style.
Tame Ducks are easy to manage, get on with the job, etc. They produce decent working code, but won't come up with the most innovative solutions. Great maintenance coders.
Wild Ducks are your innovators who will break new ground, but it's hard to get them to follow rules, comply with standards, etc. Give them the tough stuff to code.
Lame Ducks: deal with a Lame Duck by making Duck Sandwich. Sandwich the Lame Duck between a Wild Duck and a Tame Duck. They will either learn and gain competence, so becoming a Tame Duck in time, or they will Ship Out through fear of revealing their lack of knowledge.
QUACKS: talk a good project; strong tendency to bullshit their way through design by resorting to TLAs like SOA. XML and xDD. Deal with them by - again - making Duck Sandwich. The Wild Duck has exquisitely sensitive bullshit-detection capacity which, combined with their cultivated lack of tact and intolerance for freeloaders, will leave the Quack with no place to hide. The Tame Duck is there to back up the Wild Duck's assertions as to the Quack's actual performance. The Quack will almost certainly soon move on.
(Where do I fit in? ;-)
Credit: I first heard this Duck-Typing Scheme from an important mentor in my career, Nat Lunn, sometime around 1990, and so I must credit the whole story to him. Thanks, Nat!
Tame Ducks are easy to manage, get on with the job, etc. They produce decent working code, but won't come up with the most innovative solutions. Great maintenance coders.
Wild Ducks are your innovators who will break new ground, but it's hard to get them to follow rules, comply with standards, etc. Give them the tough stuff to code.
Lame Ducks: deal with a Lame Duck by making Duck Sandwich. Sandwich the Lame Duck between a Wild Duck and a Tame Duck. They will either learn and gain competence, so becoming a Tame Duck in time, or they will Ship Out through fear of revealing their lack of knowledge.
QUACKS: talk a good project; strong tendency to bullshit their way through design by resorting to TLAs like SOA. XML and xDD. Deal with them by - again - making Duck Sandwich. The Wild Duck has exquisitely sensitive bullshit-detection capacity which, combined with their cultivated lack of tact and intolerance for freeloaders, will leave the Quack with no place to hide. The Tame Duck is there to back up the Wild Duck's assertions as to the Quack's actual performance. The Quack will almost certainly soon move on.
(Where do I fit in? ;-)
Credit: I first heard this Duck-Typing Scheme from an important mentor in my career, Nat Lunn, sometime around 1990, and so I must credit the whole story to him. Thanks, Nat!
13 September 2010
Setting up a PPTP VPN with KDE NetworkManager
Filed under "Notes to Myself". If this helps someone else out there, Good!
The problem: to VPN into a closed Microsoft-dominated network.
After 6 weeks of hacking at it, the client's network administrator finally managed to get the VPN set up on their office server (some version of Windows is involved, so no wonder it is an opaque and difficult process taking weeks and involving numerous reboots. I am frequently moved to wonder whether people actually enjoy the pain that results from using Microsoft software... I can't think of any other reason to use it.)
So it helps to have the admin tell you:
The rest of the trouble comes from Kubuntu Linux insisting on using the fucked-up awful NetworkManager. I could not find reliable/working information on setting up the correct config by hand, so was forced to rely on NM. Also tried Kvpnc, but could not make it work for the client network configuration.
NM insists on setting the default route for all network traffic to be via the VPN client network. Not what I want. I need on-going access to my own local network resources as well as the VPN resources (as well as my own internet connection) as I am developing stuff that relies on local resources to work. After starting the VPN, my machine's routing table looks like
Destination Gateway Genmask Flags Metric Ref Use Iface
41.133.194.199 192.168.1.254 255.255.255.255 UGH 0 0 0 eth0
41.133.194.199 192.168.1.254 255.255.255.255 UGH 0 0 0 eth0
192.168.0.23 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
192.168.1.0 0.0.0.0 255.255.255.0 U 1 0 0 eth0
169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 eth0
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 ppp0
(192.168.1.0/24 is my own local net; 192.168.0.0/24 is the client's network.)
Note that last line. There's the troublemaker. I don't want all traffic routed to the VPN by default. I tried every possible combination of settings in the KNetworkManager applet, especially those that claim to prevent the VPN from overriding the automatic routing. I tried manually setting all the VPN info (IP address, netmasks, etc.) but that fails to work either.
Ultimately I resorted to a workaround. Accept the crappy routing that NM sets up for me, then fiddle with the routing tables by hand:
$ sudo route del -net 0.0.0.0 ppp0
$ sudo route add -net 0.0.0.0 netmask 0.0.0.0 gw 192.168.1.254 dev eth0
These 2 lines get me a sensible default route outta here, and
$ sudo route add -net 192.168.0.0 netmask 255.255.255.0 dev ppp0
gets me a route to all the client-network resources (albeit without any DNS lookups for their subdomain; this I can live without, since there are only a small handful of machines I need access to.)
The resulting routing table:
Destination Gateway Genmask Flags Metric Ref Use Iface
41.133.194.199 192.168.1.254 255.255.255.255 UGH 0 0 0 eth0
41.133.194.199 192.168.1.254 255.255.255.255 UGH 0 0 0 eth0
192.168.0.23 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
192.168.1.0 0.0.0.0 255.255.255.0 U 1 0 0 eth0
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 ppp0
169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 eth0
0.0.0.0 192.168.1.254 0.0.0.0 UG 0 0 0 eth0
Can't say it's pretty, but it works.
The problem: to VPN into a closed Microsoft-dominated network.
After 6 weeks of hacking at it, the client's network administrator finally managed to get the VPN set up on their office server (some version of Windows is involved, so no wonder it is an opaque and difficult process taking weeks and involving numerous reboots. I am frequently moved to wonder whether people actually enjoy the pain that results from using Microsoft software... I can't think of any other reason to use it.)
So it helps to have the admin tell you:
- the gateway address for the VPN
- your username and password
- the VPN protocol is PPTP (MS proprietary AFAICT) and
- that it requires some (MS peculiar) encrytion scheme (MPPE) to be used.
The rest of the trouble comes from Kubuntu Linux insisting on using the fucked-up awful NetworkManager. I could not find reliable/working information on setting up the correct config by hand, so was forced to rely on NM. Also tried Kvpnc, but could not make it work for the client network configuration.
NM insists on setting the default route for all network traffic to be via the VPN client network. Not what I want. I need on-going access to my own local network resources as well as the VPN resources (as well as my own internet connection) as I am developing stuff that relies on local resources to work. After starting the VPN, my machine's routing table looks like
Destination Gateway Genmask Flags Metric Ref Use Iface
41.133.194.199 192.168.1.254 255.255.255.255 UGH 0 0 0 eth0
41.133.194.199 192.168.1.254 255.255.255.255 UGH 0 0 0 eth0
192.168.0.23 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
192.168.1.0 0.0.0.0 255.255.255.0 U 1 0 0 eth0
169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 eth0
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 ppp0
(192.168.1.0/24 is my own local net; 192.168.0.0/24 is the client's network.)
Note that last line. There's the troublemaker. I don't want all traffic routed to the VPN by default. I tried every possible combination of settings in the KNetworkManager applet, especially those that claim to prevent the VPN from overriding the automatic routing. I tried manually setting all the VPN info (IP address, netmasks, etc.) but that fails to work either.
Ultimately I resorted to a workaround. Accept the crappy routing that NM sets up for me, then fiddle with the routing tables by hand:
$ sudo route del -net 0.0.0.0 ppp0
$ sudo route add -net 0.0.0.0 netmask 0.0.0.0 gw 192.168.1.254 dev eth0
These 2 lines get me a sensible default route outta here, and
$ sudo route add -net 192.168.0.0 netmask 255.255.255.0 dev ppp0
gets me a route to all the client-network resources (albeit without any DNS lookups for their subdomain; this I can live without, since there are only a small handful of machines I need access to.)
The resulting routing table:
Destination Gateway Genmask Flags Metric Ref Use Iface
41.133.194.199 192.168.1.254 255.255.255.255 UGH 0 0 0 eth0
41.133.194.199 192.168.1.254 255.255.255.255 UGH 0 0 0 eth0
192.168.0.23 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
192.168.1.0 0.0.0.0 255.255.255.0 U 1 0 0 eth0
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 ppp0
169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 eth0
0.0.0.0 192.168.1.254 0.0.0.0 UG 0 0 0 eth0
Can't say it's pretty, but it works.
03 August 2010
Measuring Progress in Software Development
Background
I am about to take on the leadership of a new, still-in-formation developer team, on a project - the first of several - of critical importance to the client. This means that everything is up for negotiation: team structure, development methodology, coding styles, frameworks to be used,... everything!
Initially my role was confined to that of Consulting Architect, but, by force of circumstance, has evolved to Architect and Team Leader pro tem for a few months while the client gets their dev team properly resourced and settled-in. Naturally I'm trying to help that along as best I can.
Methodology
The client initially planned to use a BDUF (Big Design Up Front), waterfall approach to the project. The requirement is extremely well-known and quantified, in a very well understood business domain.
I have never believed in my tummy that BDUF is in any sense realistically or practically achievable, though, even long before the Agile Movement tore the idea to shreds. It is impossible to foresee every detailed design element, no matter how hard you work at it. On the other hand, some Agile proponents seem to say that no up-front design is necessary... Perhaps my hearing is playing tricks with me. I cannot agree with them, either.
So call me a proponent of SDUF: Some Design Up Front.
And on the Process front, I don't think there's a lot to argue about when we contrast a waterfall/sequential process with an agile/incremental process. For me the critical difference lies in how we report and feed-back progress and how frequently we do this. And what we do about the feedback we receive - how flexibly we accommodate direction changes from customers, business sponsors, unit-tests,... to change the still-in-the-pipeline development and requirements without completely trashing the budget and time-to-market constraints. An also-essential aspect of agile development is "to reflect on what has gone before, and to adjust what we do to make
things better." [Ron Jeffries]
Waterfall possibly still does have a place in some circumstances. I can't honestly say that I've ever actually been party to such circumstances, though I've certainly been on projects where some of our business partners thought they needed hard, contractual milestones with no going back. (In reality we always "went back" anyway, when necessary, after some amount of renegotiation.)
Metrics
A very greenfield situation, this, which some people would immediately call a "wonderful opportunity", but which I very much see as a "two-edged weapon"...
The question that has been most on my mind is, "What should we measure?"
I am a very firm believer in the old saw, "Tell me how you Measure me, and I'll tell you how I Behave."
Measure a sales-person by the number of sales, and you'll get a high order volume of the easiest-to-sell products, regardless of whether they represent the best margins or quality-of-business for the company. Measure the same sales-person by margin-value of product, and you'd best hope that your high-margin products are ones that lots of people want to buy. Measure them by the number of sales calls they make and you'll have lots of calls that don't result in sales.
Here is where I believe that some Scrum proponents are going wrong... We take Features and break them up into Tasks - the developers' unit-of-work. And they measure Task completions using a burn-down chart of Tasks completed versus time. This can easily result in a situation where many Tasks are being completed, but not so many Features. A situation where Features reach an 80%-complete state, and then get stuck, for any of a variety of reasons, all of which amount to "Nobody wants to complete those Tasks" because they're boring,... or they're "just" test Tasks,... or they're difficult (because not well understood), or...
The solution is really simple. Just measure Feature completion instead of Task completion. Then the team only gets rewarded when Features or User Stories get completed. We only get beer and Pizza when the Business gets value.
But is this enough? Can we go further? Is there a way to tie developer reward directly to delivered Business Value?
In the situation I'm headed into, Business Value should be pretty easy to quantify: The product to be built is one that will directly generate revenue for the company, so we can very easily quantify how much Business Value the software is generating. (Successful completion of the product will also deliver a huge strategic Business Value by enabling new revenue streams, but that's also quite easy to quantify, and, indeed, is the prime reason the client is taking on this quite substantial investment in the first place...)
Are there ways to close the loop? To feed-back to the dev team on how much business-value their efforts are generating without making money too much of an up-front issue? Then, too, I have a reservation: Developers can have notoriously short memories, and the sort of value we're talking about here is only delivered on longer time-scales... Maybe it's good to have both long-time-loop feedbacks as long as we also have the short-timespan feedback in place as well... Waterfall's failures are largely a result of too little feedback taking too much time for us to correct project course when we need to.
My instinct is that moving towards a continuous deployment process (the step beyond continuous integration) might help to shorten this feedback loop, which is completely the point of "agile" thinking, but I'm still not really clear on how we might implement it.
I am about to take on the leadership of a new, still-in-formation developer team, on a project - the first of several - of critical importance to the client. This means that everything is up for negotiation: team structure, development methodology, coding styles, frameworks to be used,... everything!
Initially my role was confined to that of Consulting Architect, but, by force of circumstance, has evolved to Architect and Team Leader pro tem for a few months while the client gets their dev team properly resourced and settled-in. Naturally I'm trying to help that along as best I can.
Methodology
The client initially planned to use a BDUF (Big Design Up Front), waterfall approach to the project. The requirement is extremely well-known and quantified, in a very well understood business domain.
I have never believed in my tummy that BDUF is in any sense realistically or practically achievable, though, even long before the Agile Movement tore the idea to shreds. It is impossible to foresee every detailed design element, no matter how hard you work at it. On the other hand, some Agile proponents seem to say that no up-front design is necessary... Perhaps my hearing is playing tricks with me. I cannot agree with them, either.
So call me a proponent of SDUF: Some Design Up Front.
And on the Process front, I don't think there's a lot to argue about when we contrast a waterfall/sequential process with an agile/incremental process. For me the critical difference lies in how we report and feed-back progress and how frequently we do this. And what we do about the feedback we receive - how flexibly we accommodate direction changes from customers, business sponsors, unit-tests,... to change the still-in-the-pipeline development and requirements without completely trashing the budget and time-to-market constraints. An also-essential aspect of agile development is "to reflect on what has gone before, and to adjust what we do to make
things better." [Ron Jeffries]
Waterfall possibly still does have a place in some circumstances. I can't honestly say that I've ever actually been party to such circumstances, though I've certainly been on projects where some of our business partners thought they needed hard, contractual milestones with no going back. (In reality we always "went back" anyway, when necessary, after some amount of renegotiation.)
Metrics
A very greenfield situation, this, which some people would immediately call a "wonderful opportunity", but which I very much see as a "two-edged weapon"...
The question that has been most on my mind is, "What should we measure?"
I am a very firm believer in the old saw, "Tell me how you Measure me, and I'll tell you how I Behave."
Measure a sales-person by the number of sales, and you'll get a high order volume of the easiest-to-sell products, regardless of whether they represent the best margins or quality-of-business for the company. Measure the same sales-person by margin-value of product, and you'd best hope that your high-margin products are ones that lots of people want to buy. Measure them by the number of sales calls they make and you'll have lots of calls that don't result in sales.
Here is where I believe that some Scrum proponents are going wrong... We take Features and break them up into Tasks - the developers' unit-of-work. And they measure Task completions using a burn-down chart of Tasks completed versus time. This can easily result in a situation where many Tasks are being completed, but not so many Features. A situation where Features reach an 80%-complete state, and then get stuck, for any of a variety of reasons, all of which amount to "Nobody wants to complete those Tasks" because they're boring,... or they're "just" test Tasks,... or they're difficult (because not well understood), or...
The solution is really simple. Just measure Feature completion instead of Task completion. Then the team only gets rewarded when Features or User Stories get completed. We only get beer and Pizza when the Business gets value.
But is this enough? Can we go further? Is there a way to tie developer reward directly to delivered Business Value?
In the situation I'm headed into, Business Value should be pretty easy to quantify: The product to be built is one that will directly generate revenue for the company, so we can very easily quantify how much Business Value the software is generating. (Successful completion of the product will also deliver a huge strategic Business Value by enabling new revenue streams, but that's also quite easy to quantify, and, indeed, is the prime reason the client is taking on this quite substantial investment in the first place...)
Are there ways to close the loop? To feed-back to the dev team on how much business-value their efforts are generating without making money too much of an up-front issue? Then, too, I have a reservation: Developers can have notoriously short memories, and the sort of value we're talking about here is only delivered on longer time-scales... Maybe it's good to have both long-time-loop feedbacks as long as we also have the short-timespan feedback in place as well... Waterfall's failures are largely a result of too little feedback taking too much time for us to correct project course when we need to.
My instinct is that moving towards a continuous deployment process (the step beyond continuous integration) might help to shorten this feedback loop, which is completely the point of "agile" thinking, but I'm still not really clear on how we might implement it.
29 July 2010
Refresher Training is Good, Too!
Some while ago I was teaching a course -- Java Web Application Programming, as it happens -- to a group of quite-experienced web developers working in a large corporate environment. Needless to say, we all thought that this was yet another case of the Training Department getting their act together waaaay too late...
We soon discovered, however, that some of the core concepts and technologies of Java Web Application development were, at best, only poorly understood, even by the most experienced developers in the group. Many of the details of the HTTP protocol were unknown to them, as was the development of custom Tag Libraries -- a key component for developing clean, maintainable Java Web applications without in-page scripting. They had not thought much about the consequences of placing large (multi-megabyte) objects in the application Session... (this is in a clustered web-container environment!)
This is not a criticism of those developers! They had, for years, been delivering absolutely critical business functionality. This is merely an observation that technologies move on; sometimes developers need a little help to catch up, since their management usually neglects to allow time for self-study catch-up on new evolutions in the technology.
More important, it is an observation that Development Managers, Team Leaders and Project Managers shouldn't assume that their developers are completely up-to-date on the technologies they're using for day-to-day development.
Replicated from http://coco.co.za/wiki/KeyTechnologyTrainingStory
We soon discovered, however, that some of the core concepts and technologies of Java Web Application development were, at best, only poorly understood, even by the most experienced developers in the group. Many of the details of the HTTP protocol were unknown to them, as was the development of custom Tag Libraries -- a key component for developing clean, maintainable Java Web applications without in-page scripting. They had not thought much about the consequences of placing large (multi-megabyte) objects in the application Session... (this is in a clustered web-container environment!)
This is not a criticism of those developers! They had, for years, been delivering absolutely critical business functionality. This is merely an observation that technologies move on; sometimes developers need a little help to catch up, since their management usually neglects to allow time for self-study catch-up on new evolutions in the technology.
More important, it is an observation that Development Managers, Team Leaders and Project Managers shouldn't assume that their developers are completely up-to-date on the technologies they're using for day-to-day development.
Replicated from http://coco.co.za/wiki/KeyTechnologyTrainingStory
21 June 2010
Nedbank Service Fail
<span style="font-style: italic;">Rant ahead. Feel free to leave now.<br /><br />No, really! This is just whining in public about the unbelievably crapulatious service Nedbank dishes out to its customers.</span><br /><br />A service I recurringly buy, and have repeatedly bought for... oh, probably more than 5 years, now... using the self-same <span style="font-weight: bold;">Nedbank</span> credit-card... came up for renewal yesterday. Mysteriously the transaction failed, so the vendor sent me an email to let me know. Very odd! As I say, it has worked fine for years. The card has not expired - the only reason transactions have failed before now.<br /><br />Oh well, off to pay the invoice manually. Using the same card, naturally. (It's the Business card, you see, so simpler for tax and accounting than using a personal card.)<br /><br />Next thing, I find my browser redirected to some foreign website "bankserv.co.za" for "verification". <span style="font-style: italic;">Oh yeah?!</span> There's a crappy, pixelated copy of a Nedbank logo at the top. <span style="font-style: italic;">That sure looks convincing!</span> And they're asking me for all sorts of account details, including my CVV number, ID number, and some arbitrary and mysterious field labeled only "Personal".<br /><br /><span style="font-style: italic;">What sort of phishing operation is this?</span><br /><br />Actually it turns out to be an alleged "Fraud Prevention" thing called 3-D Secure. I've only heard of it because I know people who have had the pain of implementing payment solutions that use it.<br /><ul><li><span style="font-weight: bold;">Question</span>: Why did Nedbank not <span style="font-style: italic;">bother</span> to communicate to their customers that they would be requiring this much-changed payment process?</li><li><span style="font-weight: bold;">Question</span>: Why do Nedbank not do it on <span style="font-style: italic;">their own website</span>, instead sending me to some website who's identity is a complete unknown to me?</li><li><span style="font-weight: bold;">Question</span>: Is this not the most incredibly stupid thing to do in a web where phishing and identity theft is rife?</li></ul>Later, a call to Nedbank's unbelievably crappy customer "service" centre illuminated a whole lot of these details. The bottom line is that:<br /><ol><li>Nedbank <span style="font-style: italic;">absolutely require</span> us to use this 3-D Secure thingie.</li><li>The shitty 3-D "secure" thingie absolutely requires that I enter my cellphone number to complete their process. Unfortunately, where I live, cellphone reception simply does not exist, so <span style="font-style: italic;">not an option</span>.<br /></li><li>So: I have no way to complete their crappy process, and</li><li>Nedbank has no other process.</li></ol><span style="font-weight: bold;">Fail!</span><br /><br />The 3-D Secure form did not even have a field labeled "Cellphone number". How is anyone supposed to guess at this?<br /><br />Then, too, there is no way to opt out. They claim that the 3-D Secure process is to "verify my
identity". This despite the fact that they have all my FICA docs on
record. They have my other business account details on record (because
that's how they get paid every month) and they manage to successfully
send me statements every month, and a new card every couple of years.<br /><br />And the process <span style="font-style: italic;">absolutely requires</span> that I be reachable by cellphone. What if I don't have or want one? What if I have one but can't get reception? Has anybody pointed out to the shit-heads at Nedbank that <span style="font-weight: bold;">SMS is not a secure nor reliable channel of communication</span>?<br /><br /><ul><li><span style="font-weight: bold;">Question</span>: Why would I <span style="font-style: italic;">jump through all these hoops</span>, put up with really shitty service and all this pain from Nedbank when Standard Bank (my other, other bank) have been trying to give me a business credit-card for years, only to be turned down (because why would I want <span style="font-style: italic;">another</span> credit card?)</li><li><span style="font-weight: bold;">Question</span>: <span style="font-style: italic;">How quickly can I close this Nedbank account?</span></li><li><span style="font-weight: bold;">Question</span>: Did anybody at Nedbank <span style="font-style: italic;">bother to turn their brains on</span> when thinking about this process, or were they - as usual - operating with their heads stuck so far up their own arse that they could see out their own throat?</li></ul><br />Oh! I paid the invoice using my personal credit-card (Standard Bank.) Payment went through flawlessly, painlessly and instantly with no hoops to jump through.
09 June 2010
About Email
A short note on How I Handle Email communication.
Lately I've had a few people express their unease over my handling of emails, so I thought I'd write - once and for all - about how I deal with email. One of these was phoning me, worried, because I had not responded to her email within 15 minutes of her sending it. Another was complaining because emails I have sent him have never appeared in his inbox. It turned out that his ESP (email service provider) was having a Bad-Config Day.
Please remember that it is eMail. Not eInstantAnswer. Not eGuaranteedDelivery. Not eRegisteredMail. And humble though it is, I find it (still!) indispensable.
Share and Enjoy!
Lately I've had a few people express their unease over my handling of emails, so I thought I'd write - once and for all - about how I deal with email. One of these was phoning me, worried, because I had not responded to her email within 15 minutes of her sending it. Another was complaining because emails I have sent him have never appeared in his inbox. It turned out that his ESP (email service provider) was having a Bad-Config Day.
Please remember that it is eMail. Not eInstantAnswer. Not eGuaranteedDelivery. Not eRegisteredMail. And humble though it is, I find it (still!) indispensable.
Share and Enjoy!
20 May 2010
Healthy Software Projects
Love this little gem on eXtreme Programming: eXtreme Pill: Increase the odds of a lasting, healthy software project
start your journey with a Lean coach that also happens to know intimately what software development is all aboutThough it seems to come as a shock to some that such coaches actually want paying! ;-)
18 May 2010
The Way You (Probably) Use Subversion is Just Wrong
Trying to learn Hg (Take 2) I learned something about Subversion: it seems that many people are using it all wrong!
Prompted by a conversation last week with Brian which touched on Subversion and Git, I decided to have another go at grokking distributed version control. I confess that I'm probably hopelessly brain-damaged on this score; I can't help it: I started out with version control systems in the days of SCCS, graduated to RCS, was forced to deal with the abomination that was PVCS, migrated to CVS, and have largely been reasonably OK (though not ecstatically happy) with Subversion for the past several years and a half. So I can't really be blamed for my difficulties getting to grips with distributed version control, can I? I learned all I know about the subject back in the Dark Ages.
But, hey! I'm a distributed worker kind of guy. I'm sure I can figure this out, even at my advanced age.
Rather than tackle the Swiss Army Chainsaw that is Git, I thought I'd give Mercurial a second go. I lucked into Spolsky's HgInit tutorial which seems a lot more approachable than other tutorials I've seen to date, and a lot shorter than The Mercurial Book. Almost immediately I ran into a passage that stopped me short with the thought, "If this is how people are using Subversion, no wonder they want to move onto something better!"
Joel on Subversion
Wrong. All wrong!
As luck would have it I was discussing repository-management strategies just last week with a client's (new) development team, and suggesting that they use a much more aggressive strategy than they've ever seen before: Multiple checkins per day by every developer. Maybe go so far as to tie the "File-Save" key to "checkin". Anytime a developer does not make a checkin for 2 days in a row there's almost certainly a problem!
How do we achieve this without the tears and craziness described by Spolsky? Simple! Have every developer working in their own private branch. Or even flipping between a variety of private branches as they switch between tasks. (Yes, I know its not the most productive way to work, but sometimes we have to respond to demands from the outside world, so we do have to take the hit of task-switching.)
I suggested a structure where each developer simply gets a private piece of the repository to work in. Anything that's broken in there is your own problem, but doesn't affect anybody else on the team. When you're satisfied that your branch won't break the world you're ready to merge back to the main development line and integrate your work with your colleagues'. And yes, then you might have some merge conflicts, but I don't really see how any version control system can avoid this; you fix the conflicts and 'Lo! the build is intact. This does imply, though, that you want to merge quite frequently. At least every day or two. Or every time your private branch builds and tests clean. Or maybe just builds clean. All depends on your team - team size, maturity, process-maturity, personal temperaments,... One must study this very hard.
I suppose that the hangups about branching and merging come from the days of CVS, where branching was really, really expensive, and merging really, really difficult. Admittedly, too, earlier versions of Subversion were also not too hot on the merge side of things. (Though I guess it is still work-in-progress and we may yet see some improvements there.)
In recent times I have been using Subversion branches very aggressively. Frequently I'll find myself flipping between as many as 6 or 8 branches on related modules, merging them, abandoning them,... and this is on a one-man project! It means that I have to use branch-names that are pretty long and descriptive, otherwise I would soon lose myself in the forest of twisty little names.
But really, I don't see the dilemma Joel talks about in the quote above. I'll readily agree that Subversion's merging still needs some work: It can be quite counterintuitive and error prone until you get the habits right. But this Big Hairy Deal about breaking the build? Doesn't exist if you just use Subversion right!
Go forth and branch!
Maybe I'm making a mountain out of a molehill when it comes to Hg... Maybe I'll fall in love with it yet, if it makes this style of working easier for me. There's hope for the old fart, yet.
Prompted by a conversation last week with Brian which touched on Subversion and Git, I decided to have another go at grokking distributed version control. I confess that I'm probably hopelessly brain-damaged on this score; I can't help it: I started out with version control systems in the days of SCCS, graduated to RCS, was forced to deal with the abomination that was PVCS, migrated to CVS, and have largely been reasonably OK (though not ecstatically happy) with Subversion for the past several years and a half. So I can't really be blamed for my difficulties getting to grips with distributed version control, can I? I learned all I know about the subject back in the Dark Ages.
But, hey! I'm a distributed worker kind of guy. I'm sure I can figure this out, even at my advanced age.
Rather than tackle the Swiss Army Chainsaw that is Git, I thought I'd give Mercurial a second go. I lucked into Spolsky's HgInit tutorial which seems a lot more approachable than other tutorials I've seen to date, and a lot shorter than The Mercurial Book. Almost immediately I ran into a passage that stopped me short with the thought, "If this is how people are using Subversion, no wonder they want to move onto something better!"
Joel on Subversion
Now, here’s how Subversion works:No, that's not me he's talking about; that's some other Mike.
* When you check new code in, everybody else gets it.
Since all new code that you write has bugs, you have a choice.
* You can check in buggy code and drive everyone else crazy, or
* You can avoid checking it in until it’s fully debugged.
Subversion always gives you this horrible dilemma. Either the repository is full of bugs because it includes new code that was just written, or new code that was just written is not in the repository.
As Subversion users, we are so used to this dilemma that it’s hard to imagine it not existing.
Subversion team members often go days or weeks without checking anything in. In Subversion teams, newbies are terrified of checking any code in, for fear of breaking the build, or pissing off Mike, the senior developer, or whatever.
Wrong. All wrong!
As luck would have it I was discussing repository-management strategies just last week with a client's (new) development team, and suggesting that they use a much more aggressive strategy than they've ever seen before: Multiple checkins per day by every developer. Maybe go so far as to tie the "File-Save" key to "checkin". Anytime a developer does not make a checkin for 2 days in a row there's almost certainly a problem!
How do we achieve this without the tears and craziness described by Spolsky? Simple! Have every developer working in their own private branch. Or even flipping between a variety of private branches as they switch between tasks. (Yes, I know its not the most productive way to work, but sometimes we have to respond to demands from the outside world, so we do have to take the hit of task-switching.)
I suggested a structure where each developer simply gets a private piece of the repository to work in. Anything that's broken in there is your own problem, but doesn't affect anybody else on the team. When you're satisfied that your branch won't break the world you're ready to merge back to the main development line and integrate your work with your colleagues'. And yes, then you might have some merge conflicts, but I don't really see how any version control system can avoid this; you fix the conflicts and 'Lo! the build is intact. This does imply, though, that you want to merge quite frequently. At least every day or two. Or every time your private branch builds and tests clean. Or maybe just builds clean. All depends on your team - team size, maturity, process-maturity, personal temperaments,... One must study this very hard.
I suppose that the hangups about branching and merging come from the days of CVS, where branching was really, really expensive, and merging really, really difficult. Admittedly, too, earlier versions of Subversion were also not too hot on the merge side of things. (Though I guess it is still work-in-progress and we may yet see some improvements there.)
In recent times I have been using Subversion branches very aggressively. Frequently I'll find myself flipping between as many as 6 or 8 branches on related modules, merging them, abandoning them,... and this is on a one-man project! It means that I have to use branch-names that are pretty long and descriptive, otherwise I would soon lose myself in the forest of twisty little names.
But really, I don't see the dilemma Joel talks about in the quote above. I'll readily agree that Subversion's merging still needs some work: It can be quite counterintuitive and error prone until you get the habits right. But this Big Hairy Deal about breaking the build? Doesn't exist if you just use Subversion right!
Go forth and branch!
Maybe I'm making a mountain out of a molehill when it comes to Hg... Maybe I'll fall in love with it yet, if it makes this style of working easier for me. There's hope for the old fart, yet.
12 April 2010
Cogito Ergo Wiki
For your entertainment and delectation, I offer up a small write-up in which I muse about complexity and simplicity in the tools we choose to inflict upon our project partners.
A short excerpt:
A short excerpt:
I think that WikiMedia is a relatively terrible thing to inflict upon unsuspecting project partners who are already stressed out by the weird idea that they should contribute documentation to your project, that they might actually be asked to actually write somethingWiki Wondering: Share and enjoy.
04 March 2010
Those Damn JavaStations Just Won't Go Away
Actually, this thing - going by the dubious name of 'zero client' - looks to be something more like a SunRay than a JavaStation NC.
I have what is probably one of the only production JavaStations left in the world sitting downstairs - by the front door - waiting to get dumped for recycling. It is not one of those original concept JavaStations - youknow, the one that looked like the Heart Of Gold starship with Infinite Improbability Drive. Rather it was one that actually worked, looking more like a conventional PC, but with an odd (smart-card) slot in the front. It was part of a special production-run that Sun did for a client about 10 years ago which deal fell into disarray when the Left Hand of Marketing failed to talk to the Right Hand of Management at Sun, and they canned the entire JavaStation concept. As a result a couple of thousand of these JavaStations got dumped and the customer got the contract fulfilled by other means.
Actually, it would make a nice X terminal when running Linux. You'd just have to reflash the BIOS.
It occurs to me that there must be some JavaStation nostalgia buff out there that might want it. Any offers?
I have what is probably one of the only production JavaStations left in the world sitting downstairs - by the front door - waiting to get dumped for recycling. It is not one of those original concept JavaStations - youknow, the one that looked like the Heart Of Gold starship with Infinite Improbability Drive. Rather it was one that actually worked, looking more like a conventional PC, but with an odd (smart-card) slot in the front. It was part of a special production-run that Sun did for a client about 10 years ago which deal fell into disarray when the Left Hand of Marketing failed to talk to the Right Hand of Management at Sun, and they canned the entire JavaStation concept. As a result a couple of thousand of these JavaStations got dumped and the customer got the contract fulfilled by other means.
Actually, it would make a nice X terminal when running Linux. You'd just have to reflash the BIOS.
It occurs to me that there must be some JavaStation nostalgia buff out there that might want it. Any offers?
24 February 2010
Invalid Field Feedback Failure
Random musing on UI misdesign
A particular egregious error (seen in websites too numerous to list) is to validate a form, rejecting some field's value as invalid input, and then not telling the user the correct or acceptable values/formats. In other words, leaving the poor user in the dark over what they did wrong.
Only the most motivated and perseverant user will try more than once or twice before simply giving up and going away. And you will fail to capture some information/data the presumably would have been of some value. (Otherwise why would you have constructed a form in the first place?)
Example: Dzone user-profile editing rejects phone numbers entered in a format identical with the example displayed below the phone-number input field, and never provides and explanation of why. Just "Invalid input" over and over again. Result: users do not (cannot) provide valid registration information.
Somehow this failure is even worse when your form absolutely refuses to accept an entry that is perfectly valid in the user's world, but, through your own ignorance or provincialism, you reject as invalid in your own part of the world. A classic example of this crops up on websites requiring a postal-code (zip-code) as part of their input, but insist that postal codes contain exactly 5 or 9 digits. This might be a requirement for valid postal-codes in some parts of the world, but it is patently false for the vast majority of global users. Admittedly this problem has abated some over the past 10 years, but not enough, yet.
So: When you reject a user's input, please tell them how to provide something you will accept. Even better, use input mechanisms that only produce valid values in the first place, and both you and your users will be happier. e.g. Clicking on a map to indicate a position is inherently easier and more error-proof than typing in a latitude and longitude into a textbox.
[Repost from http://mikro2nd.net/bits/Wiki.jsp?page=UIDesign]
A particular egregious error (seen in websites too numerous to list) is to validate a form, rejecting some field's value as invalid input, and then not telling the user the correct or acceptable values/formats. In other words, leaving the poor user in the dark over what they did wrong.
Only the most motivated and perseverant user will try more than once or twice before simply giving up and going away. And you will fail to capture some information/data the presumably would have been of some value. (Otherwise why would you have constructed a form in the first place?)
Example: Dzone user-profile editing rejects phone numbers entered in a format identical with the example displayed below the phone-number input field, and never provides and explanation of why. Just "Invalid input" over and over again. Result: users do not (cannot) provide valid registration information.
Somehow this failure is even worse when your form absolutely refuses to accept an entry that is perfectly valid in the user's world, but, through your own ignorance or provincialism, you reject as invalid in your own part of the world. A classic example of this crops up on websites requiring a postal-code (zip-code) as part of their input, but insist that postal codes contain exactly 5 or 9 digits. This might be a requirement for valid postal-codes in some parts of the world, but it is patently false for the vast majority of global users. Admittedly this problem has abated some over the past 10 years, but not enough, yet.
So: When you reject a user's input, please tell them how to provide something you will accept. Even better, use input mechanisms that only produce valid values in the first place, and both you and your users will be happier. e.g. Clicking on a map to indicate a position is inherently easier and more error-proof than typing in a latitude and longitude into a textbox.
[Repost from http://mikro2nd.net/bits/Wiki.jsp?page=UIDesign]
18 February 2010
MIA: Google News Upgrades
When is Google going to upgrade Google News?
I don't mean anything too radical... I really, really don't want people clicking news articles straight through to Buzz on the assumption that this somehow substitutes for real communication. I have enough noise in my life already!
But I would like to see a way to promote/demote articles that the News software decides to feed me. I'm sick to death of seeing articles for the latest car models released. Let's leave aside the fact that the articles are hideously misclassified... Helloooo, Google! It's over 100 years since cars were bleeding edge Sci/Tech! At least a promote/demote system would allow their software to learn over time that I'm never going to read articles about cars or cricket... that "How Green is Your Valentine", apart from being a bit dated at this point in time, is definitely not climate-change news...
Then, too, it would be so nice to have a way to say to Google News, "Please never show me news from source X ever again." Certain news sites are so tediously flashy that they're not worth the bother of clicking through. I'd rather just make them vanish - at least from my view of the world.
Does this mean I would only get biased, half-arsed, partial news? Of course. But that's what any of us are seeing anyway!
Ah well, its pretty unlikely that Google are paying any attention to this anyway. ;-) My real point is about software adapting to the way I work, play, communicate and view the world. I'll elaborate in another post.
I don't mean anything too radical... I really, really don't want people clicking news articles straight through to Buzz on the assumption that this somehow substitutes for real communication. I have enough noise in my life already!
But I would like to see a way to promote/demote articles that the News software decides to feed me. I'm sick to death of seeing articles for the latest car models released. Let's leave aside the fact that the articles are hideously misclassified... Helloooo, Google! It's over 100 years since cars were bleeding edge Sci/Tech! At least a promote/demote system would allow their software to learn over time that I'm never going to read articles about cars or cricket... that "How Green is Your Valentine", apart from being a bit dated at this point in time, is definitely not climate-change news...
Then, too, it would be so nice to have a way to say to Google News, "Please never show me news from source X ever again." Certain news sites are so tediously flashy that they're not worth the bother of clicking through. I'd rather just make them vanish - at least from my view of the world.
Does this mean I would only get biased, half-arsed, partial news? Of course. But that's what any of us are seeing anyway!
Ah well, its pretty unlikely that Google are paying any attention to this anyway. ;-) My real point is about software adapting to the way I work, play, communicate and view the world. I'll elaborate in another post.
11 February 2010
User Interface Redesigns
I love this quote by E. A. Vander Veer in "Why Does Facebook Keep Redesigning?"
This is more true than I care to think about! Case in point: the SA Weather Service's abomination of a website. They went from a site that, while it had its faults, was uncluttered, easy to navigate, and pretty useful to an astonishingly broad range of audiences whose weather-and-climate-information needs are wildly different: from farmers to firefighters, airline pilots to town-planners. The new site provoked such a backlash when it was first released that the Weather Service website developers were forced to put in links back to the old site in order to provide the vast swathes of information that was missing from the new one.1
Rather than ragging any further on the shitty Weather Service website, allow me to point out one fundamental driver of user-interface redesigns that E A Vander Veer seems to have missed... a reason that goes, in fact, far further than UI redesigns, but is all too often a well concealed motivation for many, many software rewrites and redesigns: We redesign and rewrite because the developers want to play around with a bunch of flavour-of-the-day, oooh-shiny-new-toy technologies.
Not knocking E A's basic insight, though... The motivation seldom comes from the users (or their legitimate representatives) themselves, but almost always from the technical insiders who want change for change's sake.
Like those who thought that adding autoboxing and varargs to the Java language was a value-add...
[1] At the same time the SAWS web designers tried to do the whole "Social Weather 2.0" thing. Sadly they missed the point completely. Any negative comments on the forums regarding the new site were silently deleted. Way to build trust, guys!
typically users aren't considered at all when it comes to software redesigns. I wouldn't have believed this if I hadn't seen it in action on countless projects in several different companies! The attitude is, "We're the experts, we know what you want and need, our redesign is making it better, and it won't take more than a few minutes for you to get up to speed."
This is more true than I care to think about! Case in point: the SA Weather Service's abomination of a website. They went from a site that, while it had its faults, was uncluttered, easy to navigate, and pretty useful to an astonishingly broad range of audiences whose weather-and-climate-information needs are wildly different: from farmers to firefighters, airline pilots to town-planners. The new site provoked such a backlash when it was first released that the Weather Service website developers were forced to put in links back to the old site in order to provide the vast swathes of information that was missing from the new one.1
Rather than ragging any further on the shitty Weather Service website, allow me to point out one fundamental driver of user-interface redesigns that E A Vander Veer seems to have missed... a reason that goes, in fact, far further than UI redesigns, but is all too often a well concealed motivation for many, many software rewrites and redesigns: We redesign and rewrite because the developers want to play around with a bunch of flavour-of-the-day, oooh-shiny-new-toy technologies.
Not knocking E A's basic insight, though... The motivation seldom comes from the users (or their legitimate representatives) themselves, but almost always from the technical insiders who want change for change's sake.
Like those who thought that adding autoboxing and varargs to the Java language was a value-add...
[1] At the same time the SAWS web designers tried to do the whole "Social Weather 2.0" thing. Sadly they missed the point completely. Any negative comments on the forums regarding the new site were silently deleted. Way to build trust, guys!
04 February 2010
Software Design
"System Design, is one that as a profession we talk about less than I believe we should. It is, in many ways, the most important and most difficult thing that we engineers attempt to do. I believe that we avoid talking about it because it is hard, and seems somehow “unscientific.” There are clearly some designs that are good and others that are not. But the judgment of how good a design is often seems subjective or based on aesthetic principles rather than on the cold hard facts that we are engineers who pride ourselves on forming the basis for all that we do. I hope that this essay convinces some readers that the dichotomy between science and art or engineering and aesthetics is not clear, required, or even desirable. What we do must be grounded in fact, but it also needs to be grounded in taste. We should revel in that rather than trying to cover it up. It makes what we do more difficult, but also much more interesting."-- Jim Waldo
I've been thinking a lot again, lately, about software design and how to teach it... and about how little there is out there to guide the design of good software architecture...
All part of my Quest After The Heart Of Design for the last 15 years. And maybe (just maybe!) I think I have a useful angle on it that might illuminate a path forward.
I'll say more as I develop the concept.
(And, BTW, Jim Waldo is, in my humble opinion, one of the preeminent thinkers on design alive, and one of the most interesting people I've had the privilege to meet.)
03 February 2010
Death
So Jason and I were discussing death, as we sometimes do. In particular, what to have engraved1 on our tombstones (assuming we get so lucky!)
"I told you I was ill" -- Spike Milligan
This quickly degenerated to the OO software-designer specific:
"I've been finalized..."
"I've been Garbage Collected."
"Finally, I've been taken up to the PermGen space!"
...all depends on your spiritual views, I suppose...
[1] I it just a coincidence that tombstones get engraved? Probably not.
"I told you I was ill" -- Spike Milligan
This quickly degenerated to the OO software-designer specific:
"I've been finalized..."
"I've been Garbage Collected."
"Finally, I've been taken up to the PermGen space!"
...all depends on your spiritual views, I suppose...
[1] I it just a coincidence that tombstones get engraved? Probably not.
23 January 2010
Boolean Illogic
Why do Java programmers hate the boolean XOR operator?
Is it that they are just generally ignorant about the full-eval boolean operators in general? You know, the operators that look like &, | and ^. Perhaps its that most Java developers are under the impression that they only operate on bits, an are ignorant of the fact that they operate on booleans (and Booleans with that fucking horrible autoboxing/unboxing nonsense.)
I know that 99 time out of 100 we prefer the early-out operators && and || for their efficiency, but a simple ^ can save a hell of a lot of unreadable and less-understandable if-then-else logic. For example, I've just refactored (somebody else's code)
Is it that they are just generally ignorant about the full-eval boolean operators in general? You know, the operators that look like &, | and ^. Perhaps its that most Java developers are under the impression that they only operate on bits, an are ignorant of the fact that they operate on booleans (and Booleans with that fucking horrible autoboxing/unboxing nonsense.)
I know that 99 time out of 100 we prefer the early-out operators && and || for their efficiency, but a simple ^ can save a hell of a lot of unreadable and less-understandable if-then-else logic. For example, I've just refactored (somebody else's code)
if( check ){which I find nasty as hell to be sure is doing what it's supposed to, into
if( !user.isAnonymousUser() ) doStuff();
}else{
if( user.isAnonymousUser() ) doStuff();
}
if( check ^ user.isAnonymouseUser() ) doStuff();Much easier to understand, no?
10 January 2010
How Do Development Managers Screw Up?
Here's a question, much on my mind:
What is the single most important thing that Development Managers do, or fail to do, or pay insufficient attention to, that create a friction in the delivery of working software?
Answers in comments (or email if you don't want to publicly reveal details) please!
By "Development Manager" I don't just mean those people who have those words in their job title, but I mean any person who is responsible for tasking development teams - large or small - and ensuring the delivery of software systems by their developers. Sometimes they are called Project Managers, sometimes - in small entrepreneurial startups - they are the Boss Of The Whole Gig. The point is that they are the interface between the business stakeholders and the technical people who do the development and implementation work.
What is the single most important thing that Development Managers do, or fail to do, or pay insufficient attention to, that create a friction in the delivery of working software?
Answers in comments (or email if you don't want to publicly reveal details) please!
By "Development Manager" I don't just mean those people who have those words in their job title, but I mean any person who is responsible for tasking development teams - large or small - and ensuring the delivery of software systems by their developers. Sometimes they are called Project Managers, sometimes - in small entrepreneurial startups - they are the Boss Of The Whole Gig. The point is that they are the interface between the business stakeholders and the technical people who do the development and implementation work.
06 January 2010
New Courses Scheduled
Courses newly scheduled:
Please contact me directly if you're interested. Places are limited, especially for the Design Patterns course.
More to come soon... if you're interested, I suggest that you keep track of my course schedule page feed (the feed-link is near the top-right), or course-schedule calendar in your feed-reader.
- Patterns of OO Design, 17-19 Feb in Cape Town
- OO Technology Overview for Managers, 22 Feb, Cape Town.
Please contact me directly if you're interested. Places are limited, especially for the Design Patterns course.
More to come soon... if you're interested, I suggest that you keep track of my course schedule page feed (the feed-link is near the top-right), or course-schedule calendar in your feed-reader.
Subscribe to:
Posts (Atom)
