Its ready when its ready

I want to explore this in a non-Xojo related conversation - strictly this is not to challenge Xojo’s policy on dates, it is to test if and how it works for me and you.

So, how can I realistically tell my (or how can you tell your) customers that delivery is open ended - Its ready when its ready? How does it work for you and if it does work and how do you justify it?

A little background,

Something interesting started in another conversation and then a Xojo person locked the thread as I guess it was felt that it was getting too hot when Brad jumped in (as is often the case) and took it off in a more personal direction. However I was keen to read and learn from the responses.

By the way Brad if you are reading, I do find your ideas interesting and you very often do make good and valid points even if your style is a bit abrasive so do feel free to give your ideas as I do value them - I have even quoted you below with one of your one liners that stays in my mind from an August conversation.

For myself I usually work on large projects that have been a mixture of commercial and government/state. Usually these projects run for a minimum of one year and involve analysing, designing and developing an IT system. Typically my commercial clients are keen on monitoring and meeting deadlines and tend to set meaningful intermediate milestones as a way of measuring progress and typically my government clients are more relaxed and focus on the ‘bigger picture’, not wanting to know about day-to-day problems.

Last night I was listening to the radio while driving, normally I want to hear thumping electronic dance music but for some reason last night I just wanted to hear people talking so I tuned in to BBC Radio 4, often boring but last night it was about UK government IT projects and specifically the Universal Credit system which has been dubbed as a £2.4 billion IT disaster already with £303 million spent and £34 million written off on a system that only processes 1% of potential claimants. You can read & watch more at The Telegraph or Huffington Post and watch the government minister try and look convincing. The core problem is that this government work was commissioned on a time & materials basis - Its ready when its ready again.

In IT we have had evolving knowledge/techniques/methodologies and they all contribute something to our knowledge. Some obvious references that I have personally found to be useful and may inspire some responses are:

Parkinson’s Law
Work expands so as to fill the time available for its completion.

Hofstadter’s Law
It always takes longer than you expect, even when you take into account Hofstadter’s Law.

Student syndrome
Student syndrome refers to the phenomenon that many people will start to fully apply themselves to a task just at the last possible moment before a deadline. This leads to wasting any buffers built into individual task duration estimates.

The Pygmalion effect
The Pygmalion effect is the phenomenon in which the greater the expectation placed upon people, the better they perform.

Real programmers ship. All you need to know.
Brad Hutchins

How does a project get to be a year late?.. On day at a time.
Fred Brooks

The bearing of a child takes nine months, no matter how many women are assigned.
Fred Brooks

When to use iterative development? You should use iterative development only on projects that you want to succeed.
Martin Fowler

[h]Lean Software Development (LSD) Principles[/h]
Eliminate waste
Amplify learning
Decide as late as possible
Deliver as fast as possible
Empower the team
Build integrity in, See the whole.

[h]Agile Principles[/h]
Customer satisfaction by rapid delivery of useful software
Welcome changing requirements, even late in development
Working software is delivered frequently (weeks rather than months)
Working software is the principal measure of progress
Sustainable development, able to maintain a constant pace
Close, daily cooperation between business people and developers
Face-to-face conversation is the best form of communication (co-location)
Projects are built around motivated individuals, who should be trusted
Continuous attention to technical excellence and good design
Simplicity—the art of maximizing the amount of work not done—is essential
Self-organizing teams
Regular adaptation to changing circumstances

“Real artists ship” - Steve Jobs

They have a roadmap that was presented at XDC and if I recall was discussed in a blog post.

Interesting and perhaps the original thought for Brad’s quote - but I would like to keep it non-Xojo please otherwise we will probably get the thread locked for Xojo bashing and that is not my intention.

Apple have had success in delivering, admittedly they have huge resources (in their case more like governments) and delivery huge products to strict deadlines (more like commercials). Any insights on how they manage that internally? How do they keep their software development on track?

I think the biggest difference here is between how a Developer (you and I) have to handle deadlines, and how XOJO has to handle them.

You and I create a contract with our Client. That client which is a agreement made BEFORE services rendered, indicates that YOU will provide your client XYZ product and/or services on or before date ABC in exchange for a payment of Z Dollars (euros etc) .

Xojo on the other hand made and makes no such commitment. They have never indicated what product XYZ will be (updates to XOJO, a new iOS version), nor have they commited to an exact delivery date. Basically all they have commited to is that you are eligible to recieve and/all updates/upgrades to your current product suite for such a time as you license is active.

And no I do not work for, nor do I have any affliation with XOJO other than being a paid licensed client.

One issue to consider is that estimates early in process have a wider confidence interval than those made towards the end. In the book Software Estimation: Demystifying the Black Art they discuss the Cone of Uncertainty.

One recommendation that I stole from that book was to use empirical data from prior projects to estimate future projects. I use Task Timer 5 from BKeeney software. Then for future projects I look back and see how long it took me to create a database shema in the past. Then do a little extrapolation and interpolation since the current project may be bigger or smaller or have some other twist. So it’s not exact but I find that it’s more accurate than my back of the envelope guess which is always wildly optimistic. That occurs because we consider all of the easily recalled issues involved in creating the software due to the availability heuristic) without considering some of the important unknown implementation issues.

One major difference is that when I contract with a client I am not creating totally new software. Most projects are rinse and repeat of fundamental stuff that we’ve done before with the occasional interesting twist. When I give an estimate I have a pretty good idea on what I need to do long before I write it up. I’m also not counting on a new release of Xojo. I estimate with the tool I have right now because it’s the only one I can make an estimate from.

What Xojo is doing is new and untested. There may be a Mac, or Windows, or Linux solution but rarely is the solution the same for all three platforms, and desktop and console applications. Every decision has an impact that might have to be scrapped once you get into the details. If it was easy there would be a lot of other solutions out there. Instead there are only a few.

Carl, before saying that I took it in a personal direction, maybe look at how the OP of that thread replied to me. And with that, the only “personal” thing I did in that thread was to like official comments that 100% backed up what I wrote. If my disagreeing with what passes as “common wisdom” in some circles here yet does not jibe with reality counts as “taking things in a personal direction”, that’s on someone else.

Reading your post, Carl, it appears that you think “it’s ready when it’s ready” is a bug. For a firm the size of Xojo, it’s a feature. It says that they’re taking ownership in what they do, in every sense of the word. Having been in this software business for 25+ years, I find it refreshing.

To the Apple example… When Apple bought NeXT, I was given several official briefings, as I was a poster boy 3rd party developer on a very high profile technology at the time. They had charts, timelines, and supportive quotes from existing Apple and new NeXT execs. They had a bagel bar with locks and capers and a barista for one personal briefing. It all turned out to be horse pucky, and was the most important lesson I ever learned in this business: Only believe what is actually there. It’s ready when it’s ready is not a brush off. It’s actually the highest form of professional respect that can be paid to all of us who’ve learned that lesson.

Even when I do a new report in VBA, which I can do mostly asleep, then some surprises can happen. So software sometimes is ready when it’s ready.

Your example with the Universal Credit with the funny name sounds familar. Doesn’t every country have it’s projects that drag on and on.?For Germany:

  • Health card (billions, so far no benefits at all)
  • Elena (electronic income sheet, was scrapped totally after 100 millions or so)

Even without IT you can screw up project: Berlin airport, new music hall Hamburg, new train station Stuttgart, bishop’s seat Limburg etc.

Hi Brad, lets not go too deep into the personal thing, I was just citing it as the only reason that I could imagine for locking the thread, the comments from me and you were not really off-topic on the whole but I think you went a bit ‘up into the hills’ when you were trying to deconstruct and analyse my post.

I am trying to keep this non-Xojo but to reply to the points that you make.

In that conversation I was acknowledging that I understand some of the reasons why Xojo don’t want to give out dates. At the same time it is a bit too ‘convenient’ and does not reinforce internal motivation if external questions about dates are met with such a simple response.

Like you I have 25+ years, the last 25 of which have been independent work and yes - I know and agree software development is often very difficult. I have also learned that the best developers feel deeply responsible for what they do and don’t do, responsible to themselves, their superiors and to the users, that is one place where the Pygmalion effect comes into play.

I would say that most people who take the time and trouble to try and post sensible contributions on this forum (and sure that does include you so and so many others - I am not being sarcastic) are excellent developers who fully understand the difficulty of software development and feel responsible for what the do professionally. I can understand missed deadlines, I have been there before and will be there again, and I understand how every time it happens I learn more and get better and feel the pain of letting people down even if I can explain and justify why. Developers need that experience to improve and companies need it too.

Back to your Apple commentary, yes back then Apple were in a mess. Steve Jobs comment on ‘Real artists ship’ could have been taken to mean back then that only the artists producing the charts, timelines, roadmap posters, etc. were shipping. However they and other companies have come a long way since in terms of quality and delivery. Sure they screwed up recently with iOS Maps and Tim Cook apologised here to show that he and Apple felt responsible but on the whole they are pretty good nowadays. To quote from part of his apology:

Everything we do at Apple is aimed at making our products the best in the world. We know that you expect that from us, and we will keep working non-stop until Maps lives up to the same incredibly high standard.
(Emphasis added)

Personally I disagree, to me it is just stating the obvious - and as you also wrote it is 100% true for the same obvious reason. As someone who has learned my lessons if I was managing a project (as I often do) and an external vendor could only respond with that kind of statement then I would escalate it as a huge risk, especially if single sourced for that item. If it was an internal team member then I would at the very least expect an explanation of the delay and then monitor that person’s progress carefully. I know it is not quite the same but my point is that as professionals we can understand a bit more information and make some judgement based on our own experience/knowledge even if we have not written a x-platform compiler ourselves.

Yes :slight_smile: I agree, I often say to people that with hundreds of years of engineering we still can’t build a bridge properly so how can you expect software engineering to get it right first time. The Millennium Bridge - it was ‘delivered’ in the right year but with a bit of a problem.

Londoners nicknamed the bridge the “Wobbly Bridge” after participants in a charity walk on behalf of Save the Children to open the bridge felt an unexpected and, for some, uncomfortable swaying motion on the first two days after the bridge opened. The bridge was closed later that day, and after two days of limited access the bridge was closed for almost two years while modifications were made to eliminate the wobble entirely. It reopened in 2002.
[The whole Wikipedia article is here. ]

You can read the whole article to see what the actual ‘bug’ was (2nd paragraph in the Construction section.

Sometimes “its ready when its ready” is the right answer unless you happened to like on time but busted. I worked for one person who ALWAYS delivered on time - broken or not which was pretty useless.

The bigger the project the more unknowns there are and the more outside of ones control and so the less accurate the estimate.

Missing estimates is always a demoralizing happening - but sometimes it IS the right thing to do

Let me offer another hint, specifically applying to Xojo the company. If you need more guidance about the future, do the following: (1) buy a Pro license, (2) attend XDC, (3) get into the beta program. Then keep the specifics of what you know in confidence. But even if you do these, understand that there are limits to the information they feel comfortable sharing about future plans, and they do take real ownership of their product. No matter how nicely you ask and eloquent your reasoning, you’re not going to get “this will be ready on such and such a date” very often (if at all) from them. It’s just not how they roll.

And no disrespect here, but when you have an internal team member, you have real power over their job. And you’re paying a lot for that control. With a vendor of an off-the-shelf product that you’re paying $500 or less per year, the expectation of a similar level of transparency and control is a bit disproportionate. You can, of course, demand and expect whatever you want from whomever you want. But when they look at the costs and benefits of meeting demands and expectations, they might also conclude “no”.

Brad - come on now, doesn’t that seem a bit too similar to the horse pucky situation when compared to your earlier comment below

I would happily buy a pro license if it gave me something that I needed, as it stands I would get beta access which would be useful if I understood that the iOS product was in beta and web development which, no disrespect, I would never use Xojo for professionally. When the iOS product is out in beta or final I promise you I will spend my money, no big deal to Xojo, just one more license for them but if I could rapidly make iOS apps (not mega app store sellers but corporate stuff) I could easily justify the expense many times over.

Anyways to try and get back on track - any comments about my initial question?

As I attempted to answer before… .as a Developer you CAN’T … you have to give your client a Estimated Delivery Date… but your client also knows at the time EXACTLY what you will be delivering as THEY had direct input as to the specifications… be it a new product or an update or bug fix.

XOJO (Apple, Microsoft… insert big company name) CAN, because the client (YOU) are not being told what is going to be delivered, as you had no direct input to the specifications (indirect via forums and feedback)… therefore there should be no expectation of a delivery date.

[quote=39876:@Carl Clarke]Brad - come on now, doesn’t that seem a bit too similar to the horse pucky situation when compared to your earlier comment below
[/quote]

Not at all. You take in the information as a whole, match it with past experience, and you’ll have a good sense of where things are going. You need to temper that against “use what’s available today”, of course. But you will have a good sense. I cannot overemphasize this hint enough for what you seem to be asking for. But I also can’t tell you everything I know. Read between the lines.

With the particular Apple case, managers and evangelists that I trusted trotted out charts and plans pulled out of someone’s backside and sold them to me as the new truth. Jobs put a bullet in all of that two months later. There was really no reference point for evaluating anything in the immediate wake of the NeXT acquisition.

[quote=39876:@Carl Clarke]Anyways to try and get back on track - any comments about my initial question?
[/quote]

Sure. It depends what they’re paying for. Schedules and deadlines cost lotsa cash money. General use of things I offer for general sale do not. Customers of the latter who don’t or won’t get the distinction cost me more than they’re worth. In most cases, they figure this out pretty quickly if it’s a problem, then decide how they want to proceed given what I’m actually offering.

Horse pucky aside, Brad I ‘hear’ you. I expect and wish for great things from Xojo.

I am not actually asking for Xojo to tell me anything, they have already stated their position. I am just trying to present some alternative thought and debate on the subject. I do find it a bit strange that having got ‘beat up’ metaphorically before for late delivery the chosen solution is to avoid making a commitment to avoid getting ‘beaten up’ again. We all know that things get delayed in IT and it is the pain and embarrassment that makes us professionally better and stronger next time, however it is their choice and I understand it.

hi, if i try to say to my customer that the his app will be ready when it will be ready
my typical customer fire me.
i think that “ready when it ready” is not a respectful reply, then you can think anything.
an i think that this conduct is dangerous, because people begin watch to other products.
greetings to all, J.B.

It depends entirely on who your customer is. A contractor working for a client needs estimates, that’s the nature of the business. So yes, a contractor saying “it’s ready when it’s ready” is not going to last long in the business. But that’s not the relationship in question here. This relationship is a consumer/producer relationship. In this case, Xojo does not owe anybody anything more than the information already given. In fact, this question wouldn’t have even come up if we didn’t know iOS support was already in development. Attitudes and conversations such as this will just make Xojo not want to say anything at all until finished.

Personally, I feel it is a perfectly acceptable response in the consumer/producer relationship.

Would “I don’t know” be a disrespectful reply, if it’s true? It’s saying exactly the same thing and conveying exactly the same information. In either case you’re demanding a commitment they are unwilling to make, then calling them disrespectful for not making it. That’s actually pretty disrespectful itself. And ultimately futile. You’re not going to bully them into changing how they do this.