[kqr]

I feel like a broken record for the amount of comments I've posted related to Deming and lean product development these past few days, but as Taiichi Ohno says, the biggest waste is overproduction.

A lot of the things we build into our software is complexity nobody really needs. One way of managing it is by never making it in the first place. This takes at least two things:

- Thorough discussion with the customer about what problem they really are trying to solve. They will come to you with what they think is the solution. That way leads unnecessary complexity.

- Rough economical analysis of choices. Often we do things because that's what one ought to do. Make a quick napkin calculations. A lot of the things one ought to do are not actually necessary.

There are way too many books to recommend here, but perhaps some of the most relevant are

- Deming's The New Economics, and Out of the Crisis,

- Reinertsen's Principles of Product Development Flow,

- Ward's Lean Product and Process Development.

[xupybd]

Having moved from external consult to in house dev this is so true. Most of our production systems are just spreadsheets that get emailed on schedule or trigger.

We have no web stack, no authentication required. No complex UI or UX.

It's so simple, our production manager and I sat down and came up with the system. It works very well and took a few weeks to get up and running. It would have taken months to solve the same problems with a typical web based interactive system. It's also less work and upskilling for users.

[prox]

That sounds deliciously simple.

Same with a search for a to-do app I was looking for. Until I was thinking my file explorer was already great at filing, so I just add txt files and so on to order my projects. Naming is key if you want it to work well though.

I use Joplin for some more complex things, like keeping track of certain project features and progress.

[leandot]

Curious to hear more about that system. What do you do with those spreadsheets?

[xupybd]

It's all pretty simple. We manufacturer physical goods. Some high volume, some custom designs in an online designer with a 2 day turn around. It's all B2B.

This means various parts of our manufacturing process happen over different plants and different teams. Everyone needs to be in sync and working on the right thing. Most of the manufacturing is automated. Machine instructions are generated as orders come in. The emails send supervisors lists of what has to be worked on in that shift and department. Also they get checklists for QC, and packing instructions.

All data entry is done by scanning stickers that are generated with machine instructions and printed at manufacturing time. There is a little bit of extra info typed in for dispatch and off cut management.

It's all feed from an off the shelf ERP. Most would heavily customize the ERP. We simply hooked Jasper reports server to the db and built some custom reports. We do have some code feeding data back to the ERP.

I hope that sheds some light?

[ozim]

Unfortunately "not implementing a feature" is not my decision most of the time.

Most of the time we need to convince some customer that we can implement what he needs because even though everything is there "they are super special".

If you start with saying no - you won't get a sale, our sales of course try to explain that we are quite successful SaaS solution so they probably could work in way we propose and won't have to pay for custom development.

Mind you that it most of the time is not purely technical but often it is checking if they can get what they want so to say "checking the waters" if we are responsible vendor.

Sometimes it is just asserting dominance by asshole manager of a big company to see how far will company bend over to win the contract.

Good part is most of the time we simply get paid for "custom development" but the downside is when 1 year or 2 later such customer goes away this code stays and is not that useful for other customers.

So even if those customers pay quite a lot for custom dev, they externalize cost of software maintenance to SaaS vendor. Because I don't believe anyone is factoring that in the price even if customer pays monthly fees for 2 years, if he goes away we are left with dead code and even removing it costs money as you still have to do regression testing.

[kqr]

Yes, there are difficult customers. Sometimes they're worth taking on, and sometimes it's better to tell them "best of luck in searching for what you want with someone else."

That takes said napkin calculation, and thinking a bit like an insurance business. You can't know for sure whether you'll make or lose money on a particular customer, but you can learn to work with expectations so that your bets in aggregate make you money.

[prox]

I would like to add “About Face : on interaction design” for a solid grounding/ guide on how to manage user expectation, project re-iteration, working within scope, and working with interfaces. Knowing what stance your app has, already makes a world of difference.

Interesting recommendations u/kqr , don’t know the last two.

[agumonkey]

has anyone also included a post deploy trim phase ? even through long discussions, the client's business might be affected by the new tool in ways that may make him reevaluate workflows or distribution of work, which mean potentially reshaping the code and maybe removing more stuff.

[kqr]

The way I usually do it is any time I'm asked to fix bugs, make changes, or do other maintenance I first try to find out if the affected functionality is still relevant, or if the easiest fix is to throw it out.