3 ms·
On the flip side - building just enough software to solve the problem at hand can sometimes run circles around assembling things using off the shelf components.
by dman 8y ago
On the flip side - building just enough software to solve the problem at hand can sometimes run circles around assembling things using off the shelf components. This is especially true if something like speed / memory / correctness / optimality is important.
- randomsearch 8y agoCould you give a concrete example?
- dman 8y agoa. High frequency trading b. Embedded software c. High performance computing d. Robotics e. Military / Aviation software In each of the above fields there are categories of software where you can run circles around general solutions by writing something custom and yes some of those involve writing your own database.
- Latteland 8y agoand f. databases. ha, just kidding.
- randomsearch 8y agoI’d take exception to embedded software and robotics, where reuse and safety usually take precedence over performance, although I’d agree that a minority of such applications may be good examples. Apart from that, I agree with your list but I’d consider them to be very specialised domains that are not like the vast majority of software development, especially building conventional apps like OneNote (a document database).
- Clubber 8y agoAlso just about any software that handles business workflow. A common tradeoff in development is dynamic vs efficiency. For example, in a database, if you can define columns for properties you know about, you will have a much faster database than if you created a bunch of "Thing" tables with "ThingProperty" relationships. PATIENT ======= PatientId FirstName LastName vs THING ===== Id ThingTypeId THINGPROPERTY ============= ThingPropertyId ThingId PropertyName PropertyValue Storing it doesn't take too much of a noticeable hit, but any queries on "Thing" tables get expensive real fast.