51–60 of 130 posts
It's important to know what kind of code you're working on before you start setting low standards. Some code is perfect, but it's only perfect because it was define with extreme mathematical precision (Ex: Haskell Prelude code). The value of this type of code is in direct proportioned to how often it's reused. Often the specs are based on timeless and well defined ideas, and the implementation crystallizes. On the ot…
Earlier quoted context omitted.
Actually, I'd say writing perfect code in the mathematical domain is extremely hard - floating point types are a minefield and infinite-precision arithmetic is a minefield also if you consider the possibilities for running-times exploding. For example, code for the mean of a list of numbers is a hard problem when looked at in its full generality [1] - and that's using forgiving definition of "perfect" - alway correct…
Great link! But also, the mean is itself an imperfect summary of some distributions. Any single-number summary will be misleading in some cases.
Earlier quoted context omitted.
Enterprise apps are no different. Lean startup is doing better in the enterprise than it is in the "startup" world. Early on, every app is laden with technical debt. They barely work. When "barely works" becomes "doesn't work", we fix them just enough so they barely work again, and start piling on more features and functionality. We may build some scaffolding and do some refactoring to prevent dropping into doesn't-w…
Management doesn't invest in things they don't understand. They rarely understand tech (even if they are technical people, tech is misunderstood). If you care about the outcome of a craft, you'll get craftsmen, and they'll produce things and you'll pick the best ones. Imagine if a chef had to serve the first try at a new dish, if a photographer had to use his first shot, if a director had to use the first take, if a…
Time to market and allocation of resources are serious issues for management. They may not understand the tech, but I've found engineers rarely understand the business context, either. "Good enough" is good enough. And we've seen process get more and more focused on this since the late '90s... Agile, Lean, etc. Get a product out the door, even if it's buggy and flawed. Get feedback from actual customers. Find out what's really a problem and what we only think will be a problem.
It's important to know what kind of code you're working on before you start setting low standards. Some code is perfect, but it's only perfect because it was define with extreme mathematical precision (Ex: Haskell Prelude code). The value of this type of code is in direct proportioned to how often it's reused. Often the specs are based on timeless and well defined ideas, and the implementation crystallizes. On the ot…
I wouldn't call Haskell's prelude 'perfect'. For a few examples of imperfect things see https://downloads.haskell.org/~ghc/master/users-guide/bugs.h... (Find 'prelude' in this page, has several appearances).
The important part is the flipside, not the presentation: Given a problem domain and a context there is an optimal or "best" solution or there is not, and we can get at the answer for most cases.
So code can be perfect if we understand perfect to mean optimal. If we understand it to mean spaces/tabs probably not, though given an input and desired output we can even prove some of these as well (for instance, underscored function names are more quickly processed than CamelCase : http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.158....).
Earlier quoted context omitted.
Management doesn't invest in things they don't understand. They rarely understand tech (even if they are technical people, tech is misunderstood). If you care about the outcome of a craft, you'll get craftsmen, and they'll produce things and you'll pick the best ones. Imagine if a chef had to serve the first try at a new dish, if a photographer had to use his first shot, if a director had to use the first take, if a…
If my house is on fire, I don't want the fire department to wait for the better firetruck for the job to show up. Time to market and allocation of resources are serious issues for management. They may not understand the tech, but I've found engineers rarely understand the business context, either. "Good enough" is good enough . And we've seen process get more and more focused on this since the late '90s... Agile, Lea…
The fact is: software is a lemon market and teams/companies are rewarded accordingly.
I think this is rambling about things that are largely unimportant (spaces or tabs). At least that's what his "Perfect Code" definition seems to be to me. The important part is the flipside, not the presentation: Given a problem domain and a context there is an optimal or "best" solution or there is not, and we can get at the answer for most cases. So code can be perfect if we understand perfect to mean optimal. If w…
>Results indicate that camel casing leads to higher accuracy among all subjects regardless of training, and those trained in camel casing are able to recognize identifiers in the camel case style faster than identifiers in the underscore style.
I've seen (and written) plenty of code that was less than good enough.
I hope this attitude is used sparingly and in cases where either the problem is supremely hard or where time is exceedingly short.