Everyone should have their own personal URL shortener, shouldn't they?
I figured that this wouldn't take more than a couple of hours to write. And, indeed, the core functionality didn't take much more time than that. But then we start designing our way round the shortcuts and quick-and-dirty hacks we've used to "get things going quickly", writing unit-tests and comments explaining our thinking, adding some JSP pages so that we can exercise the whole mess, brewing a couple of batches of beer in between times... let's just leave it at a little bit longer!
Why?
Indeed! Why would anybody want Their Very Own Personal URL Shortener?
First: I don't really trust all the "cloudy" hype going around right now. For a start, I have no good reason to trust bit.ly, is.gd, goo.gl or any of the other several-dozen public shorteners. Not that I have much reason to distrust them, but really, I don't know them or the people behind them from a bar of soap. And why should I, like a sheep, participate in generating value[1] for someone who gives me little or nothing in return aside from a shorter, opaque URL that requires an extra network round-trip? And let's not forget that these entities have a nasty tendency to vanish, sometimes rather abruptly. Companies get bought and the acquiring company borgs the product, or sees no value in it, or any of a thousand other corpthink accidents may happen.
Then, too, what sort of assurance do I have that I'll ever be able to get my data (and if I shorten a reference, it's my reference) out of their service ever again? Granted that Google does make some effort in that direction (or at least nods benignly while their engineers do it), but, like the actions of the kakistocracy throughout history, things are only good until a single bad apple rots the barrel.
Second: I don't have PHP deployed on my servers and have no wish to add to the system-administration burden I already have to deal with, so I distinctly want something written in Java...
Third: A whole lot of the URL-shortening services out there don't give any analytics. At least not of those that I can self-host. I think that the analytics angle is compelling. Conventional web analytics - like Google Analytics - are only accessible to the people who created and host the content under analysis. They know where their audience came from, when and how, but nobody else does. If I refer people to some web-stuff[2] I'd like to get an idea of how many people I influenced - how many people followed my recommendation. It is a measure of my own reputation and influence, so highly personal[3]. URL-shorteners give us a way to measure, with a reasonable degree of accuracy and assurance, the influence we have in persuading others to follow our webby blatherings.
I will confess that Google's shortening service is pretty good, and has some nice-ish analytics, but I still think it's in our own best interest to keep at least some stuff out of Google's (or anybody's) mitts. Just on general principles.
An Unexpected Bonus
As it turns out, this is a really, really nice project to use for teaching a JSP/Servlet course, so I'll be reversing it into my Java web-dev course. It covers all the principles I like to get across, from container-managed security through session management and clever use of error-pages, to exploiting the underlying infrastructure properly (instead of hoping that some crapulatious web framework will substitute for your own lack of knowledge or understanding.)
Where?
I'll be releasing the code under the GNU Affero General Public License (probably via Google Code). Just have some tidying-up to do first (like getting license notices in place.) The first deployment is very feature incomplete - there's quite a bit I'd still like to add to the app - and some downright dodgy implementation details that need replacing in time, but for now its working for me.
Drop me a line if you're desperate to have it work for you and can't wait...
[1] At least I assume they get some value out of hosting their shorteners, otherwise why would they do it?
[2] I despise the word "content", despite using it quite frequently.
[3] And, YES, ego-gratifying[4].
[4] Or ego-destroying, as the case may be.
Showing posts with label software-development. Show all posts
Showing posts with label software-development. Show all posts
20 April 2011
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.
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.
Subscribe to:
Posts (Atom)
