Articles for category: Delivery

October 31, 2017

Greg Thomas

Going into a Cave

How many times have you heard a developer say this? This problem is really complex, I’m going into a cave for the next few days to work on it. So they go away for a few days and when they come out – BOOM – problem solved, new features built, product ideas are pouring out the ceiling. Two days in a Cave – no distractions, minimal interruptions, no communications – yielded – progress, delivery, initiative. We can’t always work out of our cave (wherever that is) but it’s refreshing to know that we all have that place where we yield

October 27, 2017

Greg Thomas

Leaving Uncompilable code before leaving

I can’t leave code that won’t build at my desk overnight. Perhaps it’s because I won’t remember what is wrong with it in the morning. Perhaps it’s a worry that my machine will reboot overnight and it will then be even more of a mess. Maybe it’s wanting to have that last sense of “Build Succeeded” to scroll past my screen so I always that small measure of daily accomplishment. Whatever it is, the same holds true for your customers. Don’t leave them dangling on that last minute support issue. Don’t give them wishy/washy information. Don’t push out that status

October 19, 2017

Greg Thomas

Who should write the requirements?

Everyone. Everyone fills a part of this role, from the customer to the Business Analyst, to the Sales Manager to the Product Owner to the QA Tester to the Developer. Everyone writes the requirements, everyone shapes the outcome, everyone contributes. If only one of those roles takes on the responsibility for writing the requirements than the requirements have not been written, they’ve been assumed and conjectured. Writing requirements isn’t magic, but the results they can yield when everyone contributes are.

October 13, 2017

Greg Thomas

Commenting Everything

Ask a developer to what extent they comment their code and you’ll learn something very quickly about how they approach their work and their team. Very little comments – whoever comes next can fend for themselves, just as I did. Substantive comments – this was very confusing, I don’t want the next person to have to go through all of that again. Commenting your code serves no purpose today, for you. But for the next person behind you, it can substantially reduce their time, effort and overall level of frustration in working on a similar problem. Who knows, maybe that

October 4, 2017

Greg Thomas

It Should Just Work

If a Developer on your team says this, it means the following… I have too much on my plate to really think about this. I am hoping this is not a bug. I don’t know enough about the problem to give you a solid answer. The problem with this phrase, is that the developer means it the context of – I’m not 100% sure, but I think we might be able to do something here – while whoever is asking is then taking it as 100% fact. If someone on your team is using this statement, follow up with the

© 2025 Rambli by Greg Thomas. All rights reserved.