* Posts by craigh

10 posts • joined 21 Nov 2012

Productivity knocks: I've got 99 Slacks, but my work's not done


Re: The value is all in how you use it

Can you offer a compelling reason why I should be asking myself that question? or the same question of 100 other systems and combinations out there?

It took a few minutes to setup, it was intuitive to use and without any obligation or anything more than an invite the team quickly and happily adopted it, we have it, it works very well for us, it costs nothing, people joining the team are generally familiar with it and no one has offered a compelling reason to look at anything else yet.

When we have a compelling reason to look elsewhere we will and I can only hope the adoption of that new system goes as well as it has with Slack.


The value is all in how you use it

I currently view slack as a partial substitute / partial augmentation for office conversation. It is a fairly free form place to raise and discuss issues. While nothing can fully replace in person conversation, it does have one or two advantages.

- You can control the alerts you get and how often you look at it

- You can see what others have been chatting about in the public areas and keep in touch

- It works well when your tam are not collocated every day

- It allows the quick exchange of textual information

When a decision is made, that and a clear concise statement of how that decision was reached should be captured elsewhere (in our case mostly Jira but sometimes email) by the person who needed the decision made and flagging the people that were involved. This is just like you would following a regular conversation where an important decision was made.

Like a conversation I do not expect the record to persist and make the case to my team that it should be treated just like you were talking to people not a substitute for other tools.

Used like this Slack is great but we are not all that tied to it, if something that suits us better comes along we will switch to that.

SpaceX's Falcon 9 poised to fling 350kg planet-sniffing satellite into Earth orbit


Often this is the case but given the unique orbit with its tie to the moon's orbit around the earth the wait on this occasion is a full lunar cycle until they can try again.

Space X have also had single second launch windows before

A developer always pays their technical debts – oh, every penny... but never a groat more


Our challenge is determining and tracking opportunity cost

I like the separation of cost into principle and interest but I think that is still missing another cost that needs to be taken into account.

Most often we need to decide how much time we invest in adding or extending the functional or non functional capability of the software.

This often boils down to where we make the change and we talk about stretching what we have to just achieve what is needed now vs significantly changing an element that will allow it to go further than is currently demanded much more easily.

In order to be worth the conversation the rebuilding cost (almost always time) needs to be markedly higher than what is needed for the stretch significantly delaying other things the team are being asked to do. Here we face two different costs, the certainty of any cost that the delay will cause vs the possible (but almost always eventually realised) cost of having to do what we could have done in the first place in order to deliver that further capability.

I am tempted to call it opportunity cost but no doubt someone else will have a better name and take on this problem.

Serverless: Should we be scared? Maybe. Is it a silly name? Possibly


Re: I worry the author is bluring Capabilites and Serverless Environments

@Trevor_Pott Good example, I agree that the scenario you paint is possible and even likely, its just got nothing to do with the fact that where you create this glue between black boxes is serverless.

You can create all sorts of environments for gluing API's/Black boxes together, you can offer this environment in a multi-tenanted way within any number of commercial models to different hobbyists and others to work in. You have an example of one such environment that happens to be serverless but there is nothing about it being serverless that is essential to offering what it does or what you are using it for.


Re: I worry the author is bluring Capabilites and Serverless Environments

@Doctor Syntax pointed but not necessarily true.

Our engineers have invested time in understanding this environment and the potential issues we face using it but they need to invest less in low level concerns than they did in the past and once up to speed need to invest less time in maintaining what we have done and can invest more in helping us improve what we do.

Our developers have also been brought closer to the security issues we could face meaning we two sets of eyes with different skills sets and backgrounds looking at the challenge all supported by the Cloud providers who have a vast pool of expertise and a real incentive to help us to keep things secure.

We are aware of the high profile headlines associated with cloud security but see little indication that it was caused by anything more than organisations failing to properly assess and adress where the risk to their systems and data lie in a Cloud environment.


Re: I worry the author is bluring Capabilites and Serverless Environments

@Trevor_Pott I absolutly agree that a servless environment lowers the barriers to delivering some fairly impressive looking functionality, however we have found a way to do a lot more than pull data in and out of different features.

Part of what we do in our own code involves extensive file analysis, transformation and generation. Some of this is all our own work and some utilises the same third party libraries that we have used in our native applications.

There are potential solutions to parts of what we are doing, offered as capabilities by the cloud providers however our need is very niche and not what those capabilities are aimed at meeting. The pricing model for this capability is so out of kilter for what we need at the scale that we need it that it is more cost effective to do it ourselves inside the Serverless Environment they offer for our code to run in.

This niche element does bring something else into the conversation, the impressive looking functionality that can be bolted together easily faces a significant commercial challenge if it is to become anything other than a gateway to other things.

The technical barriers to entry or competition to anything built this way is very low, if there is the slightest possibility of gaining something from a solution built in this way then competition will quickly emerge driving down the margins possibly to zero if the gains to others do not require them to earn from it. Should that application be generic enough to access a large market then you can expect to see the cloud providers bolting things together themselves and offering it in a much slicker package.

We have migrated or cancelled some work after starting it as functionality we needed within our solution became available to us and was packaged up and delivered more effectively by the cloud providers, I expect this trend to continue meaning that it is the complex niche products able to flex to customers needs that will survive being commoditised for the longest.


I worry the author is bluring Capabilites and Serverless Environments

My team differentiates between a Serverless Environment and a Capability/Service that may or may not be delivered from a Serverless Environment.

My reading of this article is that the author is describing the ability to build and offer Capabilities behind an API but there is nothing abut his descriptions that means the people offering them have to be using or benefiting from a Serverless Environment. The whole point of a Capability is that it is a black box to any other application using it, so they should not know or care what is happening under the hood.

For us a Serverless Environment is something that AWS/Azure offer us to deploy code into alongside Capabilities they offer such as a DB or Storage. We are able to deploy our code behind an end point without any concern for the underlying infrastructure that the code is running on. We know that within the limits we are paying for, each time that end point is hit our code is executed and the environment our code is in is surge resistant, resilient and scalable while still only costing us what we use.

The key element for us that makes what we are building as a dev team Serverless is that the degree of abstraction between our code and the environment we are running our code in is so great that it is no longer something we need to maintain or spend much time concerning ourselves with.

The cost of this simplicity is a significant degree of lock-in where our code is developed and optimised for the Serverless Environment we are building for. This makes each Capability we build in it pretty sticky. However the lock-in is only at a Capability level. Each Capability is a black box to the others in our solution so we can migrate some or all of our Capabilities between different environments fairly painlessly as and when our business case justifies it, running two in parallel until we are comfortable shutting down the one we are moving from (given pricing we often can just stop using the original one, leaving it there should it be needed).

'Turn to nuclear power to save planetary ecology from renewable BLIGHT'


So we have limitless sun, very low value land in the Sahara but no one there to use it. So we need a store of energy that can be easily (relative term with energy) transported to where it has more value.

Could we not build large solar farms generating hydrogen from sea water that is then transported to Europe and used to power large electricity generators, cars and maybe even homes? I would really appreciate an intelligent challenge to this.


Cost of building and maintaining solar farm - I think this is mostly solved

Getting sea water inland - canals, there is no real loss to evaporation

Desalination - the solar plant should enable this or large solar evaporators

Hydrogen transport - pipe back to the coast (built alongside/in canal) and load on to ships

Why do Smart TV UIs suck?


Looking for a great TV to use as a screen, any thoughts? 42" and above

I have put off buying a new TV for a few years now, waiting for a review or set of review that say “If you want a very good high quality stupid TV to use as a screen along with whatever you want then this is the one to get”.

I worry that buying whatever it is that makes it “smart” will get in the way or impact on the ability to use it as a screen.

Can anyone here suggest anything? (When I do find a review and comments that seem to indicate it is a good option the TV has always been discontinued, so the upgrade cycle is faster than the ability to achieve sufficient credibility)

Looking for two, one for the bedroom and one for the lounge so from 42" upwards.

Any thoughts appreciated.


Biting the hand that feeds IT © 1998–2020