Not delivering end-user value | Hacker News Reader

Not delivering end-user value

mooreds.com

59 pointsmooreds33 comments

We accomplished more in a couple weeks with this perspective than we had in the previous couple of months. This also let us commit to a real project plan and timeline. Unfortunately, the client wasn’t happy about the projected and past expense, and shut down the project weeks after the development team was starting to show traction.

It's amazing how long big companies will let consultant-led software projects go on with zero tangible progress as long as the consultants tell them that the project isn't in gear yet, they're struggling to overcome problems that pre-date them, and they have a plan to start making a ton of progress as soon as they can start working the right way that they know how to. The business doesn't have a way to forecast the project, because their forecast would have to be based on something they haven't seen yet. The minute someone says "we're making good progress" the business will extrapolate that out and realize the project is a money pit.

This is something I'm just starting to understand after being an idealist/perfectionist for most of my life.

YAGNI seemed like a shortsighted dogma. My colleague's design decisions looked like ugly hacks. I preferred something to be well-done than to be useful. According to my MBTI type, I was a perfectionist of idea, not a perfectionist of action/result. I was trying to build a cathedral, not a bazaar.

I can attribute my ongoing transformation to a single video about effective writing:

https://www.youtube.com/watch?v=vtIzMaLkCaM

The main takeaway is that text is meant to be read, not written. Providing value to the reader is the only thing that matters. How well you write, how smart you sound, how much knowledge you deliver, doesn't matter as long as the reader gets value from the text.

It sounds obvious, but it truly changed my perspective. I recommend this video to everyone.

I do consulting in the enterprise, it's not very exciting but living on the streets is too exciting. Most often when I start somewhere new it is like here is this computer, install the stuff we need and by tomorrow be productive member of the adgile sprint. Ok.

What is described in the article sounds like a luxury to me, how do I get in, what do I do wrong, tell me?

came here for this

Author here. I can tell you it wasn't much fun to thrash around trying to figure out how to build something, have it constantly change underfoot, have staff turnover on the project, and be apologizing for not delivering anything.

But maybe that's just me.

(I do think what you go through, where you get zero ramp up time, sounds pretty awful too.)

> by tomorrow be productive member

As a perm employee for the past 20 years (four different employers), this isn't just limited to consultants. "You're a senior developer! You should already understand everything that exists!"

Firstly, realize you're not a consultant. You're at best a contractor.

Thanks for the advice, it is not smart but it is clever.

Charge more. Charge enough that you aren't seen as just another warm body assembly line worker. Keep charging more until the attitude towards you changes.

How would you outline how you sell your services? What are your complementary strategies to charging more?

I found pretty much all my work through contracting firms. While employed, I only ever considered offers at current_rate + $25/hr. I noticed after a certain tier of billing rate I got "promoted" from talking to the kind of person that cold calls you asking for a resume to a different tier of salesperson. We're told ego is bad, but ego is a tool. Turn it on when talking to them, and be firm about what you deserve. Once you're off the phone with them you can crank the ego back down to normal so you're not an asshole in daily life.

If you can, find out how much the middle-man company is farming you out for. Let's say you once did a contract through ManPower for ABC company. ABC company needs some labor, and you did a good job, so they reach out to you directly. You should be billing what ManPower billed your time for, not what you billed ManPower.

This is generally only possible to do through smaller businesses. Big corporations typically have contracts where they require you to go through one of their preferred vendors.

Thanks!

The very first thing he says is that there were no (or vague) requirements/user stories. I think he should have gone back and sorted that out.

Its a pain in the ass i know, but on my current project if we didnt do that we’d be in a complete shitfest right now.

The first step to showing buisness value in reporting is showing the goal, and _then_ where you are on the path to it.

"Shape up" from Bootcamp recommends integrating one soup-to-nuts slice of functionality at a time as well (https://basecamp.com/shapeup/3.2-chapter-10).

A great read for anyone interested in simple, pragmatic, and effective approaches to shipping software.

I love that book. If you want those thoughts in a highly condensed manner, the author Ryan Singer has done a number of interviews discussing the high level concepts of Shape Up. I particularly like the Software Engineering Radio interview: https://www.se-radio.net/2019/11/episode-389-ryan-singer-on-...

> smallest bit that would possibly work

Nice thought - but I've tried that in the past, though, and smashed into unreasonable expectations from the clients themselves: "Why just do the smallest bit? We need the whole thing!" This only works if everybody understands the value, and this shared understanding is rare, to say the least.

Castle walls are built a brick at a time.

True. But one brick is not a viable castle wall.

good thing no one is advocating for laying one brick and stopping

But it's the difference between building the smallest wall to completion first versus going the whole way around the outside layer by layer.

Showing one thing that is complete is better than partial progress everywhere.

This is why you confirm progress with the client at every sprint/milestone. Unless they expect a full system built by the end of the first, this shouldn't be a problem.

If they don't understand project management, our job is to educate them. If they can't be educated for some reason, and there other clients, let them go.

Another source of such mistakes is having too small a team tackling too big a problem, and being unable to ship a solution on time, because you tackled the wrong problem.

That's typical when you approach a fairly mature category where the feature set is pretty entrenched, and people have very set expectations. To them, every feature is a must have.

The lesson here is that.. you probably shouldn't ever do that unless you have a big enough differentiation that allows you to ship just that differentiation and delivers outsized ROI for the customer, without building all the other expected stuff.

In other words, you need to unbundle the part of the value chain where you can deliver the most leverage and refactor everything around that — and not commit the biggest mistake which is rebuilding the whole thing expecting that you're going to add your "killer feature" as the cherry on top. You'll never get there.

Or the converse, where they want you to stop when the product is kind of half-assed. The pays the same, but the sense of accomplishment goes out the window.

Good, if you throw in a few more ingredients. My favourites:

1. keeping a steady compass on where it is you want to go

architecture and strategy are extremely valuable upfront investments and are real enablers for a more agile implementation process later on.

2. committing to quality on "minimum viable solutions"

An acceptable MVS should incorporate more than just ticking boxes on the functional requirements. Shipping a steady stream of rough alpha features or POC-like deliveries will not result in a great product and happy customers.

Great point about strategy and having that be a true north. This project lacked a real kickoff/strategy doc that would have been clarifying and could have been checkpointed periodically (ah, hindsight).

"1. keeping a steady compass on where it is you want to go "

Totally agree. Just keep the direction loose enough to allow for changes. In the compass analogy it would be maybe allow deviating from course by 20 degrees.

Agreed.

The hard part is that such insights come thru contemplation and reflection, things we're "too busy" to do in a vulnerable project. At the very least we're looking busy for appearance sake.

On the other hand, we often need to do a lot of this work to acquire empirical data. Details necessary to realize why a project isn't working. Thus why this kind of thing happens so often in project management, similar to a catch-22.

I agree with this but it seems a lot of people take it to the extreme stating that you should only do the minimum and never think ahead. I think it’s good to have a rough idea of where you want to go and then take very small steps toward that goal.

Getting something to work end to end, however small, is so important. In my experience the earlier you do that, the better. Otherwise you have no idea what you're building.

Yes! That's a piece of wisdom that many managers would need to learn. It seems easier to sell an ambitious rewrite with the newest tech than common sense, do what's right, fix what's wrong, baby steps work.

My corollary to this is that the biggest threat to a project is management. It is management that will cancel the project, after all. Much more than 90% of the time, they will cancel it because they are feeling uneasy about the progress. Your job, if you don't want a cancelled project, is to deliver regular progress that feels tangible to the stakeholders. Every company is different in terms of how often they need that shot of "we made progress", but every company is the same in that the longer you make them wait, the more likely it is that your project will be cancelled.

"Smallest thing that could possibly work end-to-end" is a very good strategy, if the "smallest thing" is small enough. If it's not, then you have to get even more creative. Whatever you deliver, though, it has to feel real and tangible to the stakeholders. Usually specs and design docs do not fill the bill.

It is critically important that if you want to "do it right", whatever that means to you, that you interleave the quality oriented activities within a deliverable matrix. Good specification, good design, testing, refactoring, monitoring, configuration management, etc, etc, etc are things that are invisible to stakeholders from a tanglible delivery aspect (unless you are incredibly blessed). Thus, these activities must be similarly invisible from the external view of development. Shining a spotlight on how much time you are spending on these quality aspects of development will only hasten the demise of your project. At the very best, they will be used as points of negotiation from the business side - "Could you deliver faster if you didn't test this part?". The business should be so preoccupied with looking at what you are delivering that it doesn't notice how you have delivered it.

The biggest mistake I see from developers is the idea that the business must buy into the developers' sense of values. It is, of course, wonderful if that happens, but it is rare in the extreme. Most businesses do not understand those values. To be fair, given the amount of internal bickering we tend to have as developers with respect to "doing it right", I have to say that even we do not fully understand our own values.

It is important, though, that development be able to use the practices that will give them the best shot at success. Just like a developer should not be calling the shots for strategic business direction, so too must the business stay out of our strategic development decisions. To ensure this, you must create a development process that is largely boring for a person from the business side. As soon as you link your development process with the stategic success of the company, you invite the business side to feel as though they should be calling the shots. This is almost always a mistake in my experience.

Deliver early. Deliver often. Make each delivery contain something that has tangible results for the business. Make your process boring without exceptions: "This is just how you do it" rather than "We need more time for analysis". Refactor your code when you need to without asking for permission rather than creating a task to refactor your code. Improve your build system with every small step rather than spending a month up front creating the perfect build system. However, no matter what you do, always remember that there must be delivery. Plan your activities strategically and try to work on quality uniformly.

> Unfortunately, the client wasn’t happy about the projected and past expense, and shut down the project weeks after the development team was starting to show traction.

Translation: development team did not manage customer's expectations.

I suspect this experience is pretty common. It so perfectly matches one of my experiences, I'm curious if it's the same company.

Reply on news.ycombinator.com