Ask HN: How to balance feature delivery with internal quality? | Hacker News Reader

Ask HN: How to balance feature delivery with internal quality?

1 pointcaprock5 comments

Something that's been on my mind a lot lately, is the continuum between:

a - the velocity of delivering a product and features

and

b - ensuring internal code quality, performance, and the right architecture

My personal bias leans heavily to prioritizing the delivery of minimally complete features. I've noticed though, that many software engineers focus more on code idioms, general quality, and attempting to mitigate future risks.

Is this just one of those never ending dynamics? Or do most HN folks lean one direction? Or does the answer change based on the life stage of a company?

View on HN

I think the #1 cause of both slow development and quality problems is a mismatch between the mental models an application is based on and problem domain and the needs of the users.

If the mental models are correct is is possible to add new features and fix bugs.

If the mental models are incorrect you are at best going to be pushing a bubble around under a rug and everything is going to be expensive and broken at the same time.

Frequently organizations talk as if they were making a tradeoff between speed and correctness but when that kind of talk is in effect you usually find development is slow and it is all broken. That is, talk of a "tradeoff" obscures the fact that there is one right thing to do which is bring the mental model in line with the domain and then bring the application in line with the mental model.

For instance, splitting up functionality into small features that can be deployed into small units is not "low quality", in fact it can be conducive to very high quality because an incrementally developed system can feed experience back quickly such that the system has all the right attributes.

Where people get into trouble is with data structures as opposed to algorithms.

I went through a phase where I fixed maybe 15 seriously broken applications in six months and most of the time the hardest problems was something seriously wrong with the database structure that caused errors and made it difficult or impossible to add features. Overhauling an app like that was probably 80-90% migrating the database to a proper structure, the remaining part is almost trivial when you have the right data structures in place.

If you are thinking ahead you should be able to deliver functionality in nice small increments and never find out that "oh crap, my data structures are totally wrong and I need to rewrite this."

Facebook, Adobe, Microsoft, Google, Epic and Cerner are monopolies that don't face competition that can hire expensive developers, use them poorly, and subject users to their boondoggle. Other software companies, not so much.

Very intriguing ideas. Is there a relationship here, with the concept of starting an application by thinking more about the data structures and getting those right, before proceeding with the rest of development? Or are you speaking of more abstract mental models?

The fancy way to think about it is

https://en.wikipedia.org/wiki/Refinement_calculus

That is you need to be able to think about an application at various levels of granularity.

It is important, for instance, to be able to explain the business case of your application succinctly. Everybody from your devs to the salespeople need to understand this because it informs everything else they do.

Above the level of data structures realized in Java classes, SQL tables, XML documents and such there is this subject

https://en.wikipedia.org/wiki/Ontology

which is where mental models reside. My guess is that if "low code" is going to be a reality it will require the incorporation of well-developed ontologies. For instance, there are many applications that require a customer database and even though they all have some unique requirements there are numerous things like addresses, postal codes, phone numbers, etc. To pound out high-quality applications quickly we would want to to reuse as much stuff as possible from a general ontology (offering the possibility of reusing code as well as the data structures) but still be able to customize the application as necessary while hopefully deterring people from making harmful customizations.

An example of the latter is that many applications end up having one field for a contact's phone number, learn the hard way that somebody might have two phone numbers, put in a second field for the phone number, find out there could be three, ... It's highly predictable that contacts are going to have multiple phone numbers so the right thing to do is support multiple phone numbers from the beginning and do that all the way from the database to the UI. It might be fair to let specializers put on a constraint that "for now, a contact can have at most one number" but still reuse all the stuff that supports multiple phone numbers.

You certainly don't need to plan out every single detail of data structure in advance, but I can say that if you do want to deliver a complex application in terms of little feature updates that are actually little, you will need to be thinking ahead about data, not so much about code.

> never ending dynamics

Mostly. I think it depends on the life stage of the product/app. The interesting thing about this dynamic is that if you prioritize code quality, having the "right" architecture, etc. without building the features to capture paying and keep customers then its not likely the app/product will be around long.

Make sure the app is designed to be agile enough to adapt but don't solve problems you don't have.

Speed requires quality; there is no trade-off.

Reply on news.ycombinator.com