[HN Gopher] Just Build the Product
___________________________________________________________________
Just Build the Product
Author : davnicwil
Score : 217 points
Date : 2020-01-02 10:49 UTC (1 days ago)
(HTM) web link (davnicwil.com)
(TXT) w3m dump (davnicwil.com)
| mooreds wrote:
| Whenever someone asked me what language or framework they should
| use to build their project, my default answer is "whatever you
| are familiar with". The honest truth is that for the vast
| majority of applications I have seen, the risk is in building the
| wrong thing or getting wrapped around an axle trying to figure
| new technology out, not choosing an old boring technology that
| won't scale.
| coffeefirst wrote:
| And even then, your odds of handling scaling issues with things
| you're familiar with are a lot better than with new things.
| gprasanth wrote:
| It's fun the first 2 times you do it as you like. Then you start
| thinking about doing it right.
|
| Then you start thinking about building stuff right from the
| beginning which is basically intelligence you've gathered.
|
| It takes finesse to craft things quickly but with quality.
|
| Bias to do stuff quickly is very hard to let go off. Doing things
| in an organised way has its value. Basically if you're not going
| to rewrite something in the next year, do it right now. Otherwise
| you're just borrowing time from future.
|
| Short term hacks vs long term meaning.
| gfodor wrote:
| There are path dependencies. If the short term hack accelerates
| your ability to get enough traction to increase runway, you may
| survive to see the "right" solution implemented. whereas if you
| pursued the "right" solution more directly from the beginning,
| the additional delays would have killed you. Good technical
| leadership embraces the short hack _and_ guides the project
| through righting it when the opportunity is there. (To fail to
| do either is an equal failure, and both are hard.)
|
| Anyone claiming there is a clear answer to these questions is
| deluding themselves. Tactically, the best weapon is to
| recognize your own weaknesses, and it seems to me that
| engineers often have more of a bias towards performing tool and
| technology analysis and research in the name of avoiding the
| hard and often humiliating task of shipping software that users
| will almost certainly hate in its earliest versions.
| marcosdumay wrote:
| After you learn some lessons, it's tempting to check any action
| against all of them. But that slows you down, the more
| experience you have, the slower you will be. You don't want to
| do that either.
|
| Anyway, it is very hard to stay away from both extrema. It
| requires constant self awareness, and even more learning, of
| the hardest kind where you are required to feel stupid all the
| time.
| tombert wrote:
| You know, one of these posts pops up on HN every few months, and
| every time it kind of annoys me.
|
| If I'm building a project for fun at home, then it's typically
| _specifically_ to learn about a new thing (which I kind of
| assumed was the case for most people); either a new programming
| language, or a new editor, or a new library or two. If I short-
| circuit and "just build the product", then that is sort of
| negating the purpose of the project.
|
| If I wanted to "just get something done", I probably wouldn't
| have done any projects in Haskell (back when it _really_ sucked
| for tooling), I wouldn 't have learned category theory, and I
| wouldn't have gotten any work in research.
| mathgladiator wrote:
| It annoys me as well, and I think the intent is that "just
| build the product" is about avoiding shaving the yak.
|
| Some of us poor bastards have to invent the stupid things that
| let people get things done, and it isn't exactly clear that the
| stupid thing is even good in the first place.
|
| For instance, right now, I am in the process of inventing my
| own programming language. I've done this in the past with
| varying degrees of technical success, but it tends to get deep
| into the weeds of shaving the yak and polishing it up.
|
| I'm have a hell of time to pull myself from the technically
| interesting problems to focus on the product that this language
| enables, and I find myself having to balance between fixing the
| language idioms and building the product.
|
| Balance will be a key thing to focus on if I make this product
| a real thing for real customers... very challenging future
| ahead of myself.
| eckza wrote:
| What kinds of problems are you trying to solve that would
| make solving the (rather large) meta-problem of creating a
| /whole new programming language/, easier / more effective /
| more clear / more profitable - especially when compared with
| "just solving the problem with more established tooling"?
|
| I don't ask this critically. I am genuinely curious. I wonder
| about this a lot; there are so many languages that solve the
| same problems in slightly-different ways, that I'm always
| curious as to the motivations behind creating another new
| language.
| iudqnolq wrote:
| The problem of them not being as good at creating a new
| programming language as they want to be.
|
| So many amazing projects started as someone scratching an
| itch, often completely unrelated to the eventual product.
| And even if a project doesn't take off, if the goal was to
| get better at programming (and not marketing, project
| management, etc) it may be still be a success. Both forms
| of projecting have value. It all depends on personalities
| and where people are in their careers.
| capableweb wrote:
| > It annoys me as well, and I think the intent is that "just
| build the product" is about avoiding shaving the yak.
|
| I think discussions in general on Hacker News, blogposts and
| Twitter is missing context. Everyone assumes that others
| context is the same that you yourself has. So posts like this
| make sense, if you're in "startup - lets find market fit -
| need growth - just build the damn thing" mode, which is
| probably the mode the author is, or the context would have
| been set in the blogpost.
|
| In the comment you're replying to, the context is a "explore
| an idea and learn something new" with no intention on turning
| that very thing into a product that sells to people. Maybe
| that will happen, but it's not the intention.
|
| In the end, two very different contexts, both valid, but they
| are both talking past each other. All the people using
| different social networks (HN included), usually miss the
| vital piece of context and just proclaim "You should do X,
| because of Y". Then people defend their context, because life
| is never "Always do X" and will never be.
| beat wrote:
| A lot of discussion of best language, etc, is just bikeshedding.
| (See Parkinson's Law of Triviality) We talk about technologies we
| use because it's easier and safer than talking about the actual
| _product_.
| kareemm wrote:
| This is the right advice if you want to nerd out on technology.
| But my experience suggests[1] that if you want to build a
| __business __it 'll be cheaper to validate problem/solution with
| phone calls and mocks / designs before writing code.
|
| This is because:
|
| * It's cheaper to make changes before code has been written
|
| * A functioning product isn't the best sign that you're making
| progress - paying customers are[2]
|
| Don't get me wrong. I like to write code as much as the next guy
| / gal. But I've made the mistake of writing code first. And I've
| worked with clients who - despite my best attempts - decided to
| forego validation to build a product that they spent a lot of dev
| dollars on to fix once the market met it with a trickle of
| interest.
|
| 1- https://uncog.com/archive/v2/why-only-fools-write-code-
| first...
|
| 2- https://uncog.com/archive/v2/how-to-get-paying-customers-
| bef...
| opportune wrote:
| Conversely, you cannot validate product market fit without a
| product. Validation via "Is this something you can see yourself
| paying for" isn't really a substitute for actually getting
| people to pay for your product. At best it will filter out just
| the worst ideas.
| api wrote:
| How do you get quality feedback? In my experience people will
| often say yes when asked or shown a mock up but will not buy.
| You don't find out who will actually buy until they try a
| functional product.
|
| I really suspect that the lean startup method belongs in the
| early web era when there was a ton of low hanging fruit with
| simple market research and simple MVPs. All that low hanging
| fruit has been picked. Today it's pick your brutally hard
| problem and iterate for 1-2 years before you get a MVP that you
| can test.
| kareemm wrote:
| > How do you get quality feedback? In my experience people
| will often say yes when asked or shown a mock up but will not
| buy. You don't find out who will actually buy until they try
| a functional product.
|
| Ask them to pay you based on the mocks. If they say no, ask
| why. If they say yes, take their money and give it back in N
| days if you haven't built your MVP. I've done this BTW - it
| works.
|
| > You don't find out who will actually buy until they try a
| functional product.
|
| You'd be surprised how many people have gross business
| problems that some well-placed code would solve and they'd be
| thrilled to pay you for it because the other options suck.
| shantly wrote:
| I have real trouble wrapping my head around this kind of
| thing because I can't imagine paying for a product under
| those circumstances, no matter how useful it'd be. I get
| that it must work since so many people say it does, but
| it's totally alien to me.
|
| If you don't have something to sell me, now, why are you
| asking for money? Am I an investor? No? Come back when you
| have a product. I'll probably still say no because I won't
| expect your business to last very long, but you'll be 100x
| closer to a "yes" than you are now, which is about as far
| from it as you could possibly be. Is this an unusual
| attitude?
| [deleted]
| cik wrote:
| This is the hard truth that people leave out.
|
| Just build the product - the purest most minimal version you
| can. I mean be judicious with the knife, and slice like it's
| going out of style. Accept it - you're throwing out 100% of
| the code eventually - be fine with it; it's not ideal, but
| you'll ship and be live. Add the analytics you need - test
| hypotheses. Reach out to people who drop in and drop off,
| they're more valuable than features.
|
| Don't agonize over "this isn't done", "this isn't perfect" or
| "it needs X to be useful". Get it out, charge for users, and
| you'll build a sustainable business, or it will fail quickly.
| Sure, this may not be VC sexy - but you know what, you can
| build product quickly, validate or toss and idea and move
| along or improve, based on feedback.
|
| This ships. It ships repeatedly. It's not perfect, it's not
| awesome, but it works, always.
| onlyrealcuzzo wrote:
| As someone who built probably 10 apps / businesses before I
| read the lean startup, and learned to validate things first, I
| think "JUST DO IT" is about the worst advice anyone can give
| you.
|
| Maybe I was and still am a complete idiot. But I think a lot of
| people would be like me and just assume that lots of people
| want X, Y, and Z -- so go out and build the thing, and then
| realize nobody wants X or Y, and no one is willing to pay for
| Z.
|
| I started doing financial models when I get an idea. What I
| always find out is -- even in my wildest dreams -- these ideas
| wouldn't pay more than my current job.
|
| Granted, I make a lot of money. But I think the vast majority
| of people on here make more money now than is reasonable to
| believe their business could ever make, if everything worked
| out.
| theturtletalks wrote:
| How much of that is just people wanting to make their own
| mistakes? This is one of those things where people only learn
| from making the mistake themselves.
|
| Most products are mainly built by people who face that same
| problem their app solves. This gives them a reason to build
| it. As worst, it's used internally. At best, it's a side
| hustle or much more.
| kerkeslager wrote:
| Playing devil's advocate here:
|
| This is basically an attempt to gather more information before
| you act. In principle, that's an Obviously Good Thing. But you
| have to question whether that information is actually as
| conclusive as you want it to be, and whether you're changing
| the outcome by observing it. There's two problems with the
| information you gather by making phone calls and showing
| mockups/designs:
|
| 1. Mocks/designs only communicate a fraction of the product,
| and often the parts that aren't visible in mocks/designs are
| the most valuable parts of the product. Speaking in vague
| terms: I'm working on an app where the main value is that it
| calculates actionable numeric values that users typically
| calculate in spreadsheets. The UI is certainly a selling point,
| but users aren't going to easily understand the connection
| between the new UI and the old spreadsheet formulae without
| playing with the actual product. Phone conversations are likely
| even less communicative.
|
| 2. Communication is a two-way street: releasing early allows
| you to get information from your users, but it also leaks
| information _to_ your users, which may not present the image
| you want. Kickstarter has shown that with good enough marketing
| you can get paying customers with literally nothing. But you
| can also burn customers so they never want anything to do with
| your product ever again. There are numerous high-profile
| failures-to-deliver that have killed not only products, but the
| reputations of individuals and companies. But failure doesn 't
| have to be that catastrophic to lose customers permanently: all
| that has to happen is for someone to pay for your product, find
| it a bit lackluster, and decide to cancel their subscription.
| That user is worse than a non-user, because they are never
| going to be a user again, and might tell others about their
| experience. Short term success not only isn't an indicator of
| long-term viability, it can _cause_ long-term non-viability.
|
| Sure, it's cheaper to validate problem/solution with phone
| calls and mocks/designs, but you get what you pay for.
|
| The best strategy probably lies somewhere in the middle: code a
| minimum viable product, but really make sure it's the minimum,
| and really make sure you think it's actually viable. A good
| compromise might be to release a discounted beta for select
| users--that lets you get feedback from paying customers up
| front, but also sets expectations so that users don't get the
| wrong idea about your product before it's mature enough for a
| real release. It also limits the exposure, so even if you burn
| a few beta users, you don't burn your entire potential user
| base.
| jt2190 wrote:
| > I'm working on an app where the main value is that it
| calculates actionable numeric values that users typically
| calculate in spreadsheets.
|
| Even this sentence is a perfect tool for validating the
| market: I have no idea if the product is for me! ;-)
|
| (I get that you may be keeping your product's specifics vague
| here, but by doing so you've provided a contrived example of
| how a simple description of the product itself can help find
| information about the target market. I have no idea if I'm in
| your target market, for example, so if I'm supposed to be,
| that's a problem.)
| dynamite-ready wrote:
| It's fair to say this is line of conversation is tangential to
| the original post, but respecting the passion of your reply, do
| you think ideas like those represented in The Lean Startup
| perhaps over-rationalise the creative process?
|
| Like, taking a rough guess, I wonder if there aren't as many
| successful startups, as there are successful writers. But no
| one takes those guides to writing a successful book quite as
| seriously as those guides to running or starting a successful
| business.
| truculent wrote:
| http://momtestbook.com/
| kyllo wrote:
| I read it differently--this is not targeted at founders trying
| to validate a business plan, it is targeted at engineers whose
| job it is to build the product, and he's saying to quit
| fiddling around with your tools and focus on building the
| product--which is more fun anyway.
|
| "It's important to learn how to use your tools well, but once
| you have, stop prioritising that. They're good enough now, you
| know how to use them. Don't get trapped in this local maximum
| of optimisation. Go and build stuff."
| davnicwil wrote:
| You're correct - this was the intended message :-)
| chefandy wrote:
| This was also my interpretation.
| bluedino wrote:
| 10 years ago, I wanted to learn Ruby on Rails, so I bought my
| first MacBook Pro. Just grabbed it off the shelf at the
| store.
|
| I got my first software development job, and everything was
| great. I thought it was odd that the other guys didn't know
| much about Macs (and didn't really seem to care), so when
| they'd upgrade the OS I'd have to fix everything for them, or
| they'd have issues with gems etc.
|
| I started buying every MacBook as they were relased.
| Installing beta software, upgrading the RAM and HD just
| because I could. Spending countless hours reading reviews,
| posting on forums...
|
| The other guys just wrote code. Eventually I got tired of
| keeping up with the crap (or maybe I just got older) and now
| I crank out code on my far-from-the-latest MacBook, running
| Mojave. _shrug_
|
| It was fun stuff, but I could have spent that time (and
| money) more productively.
| shantly wrote:
| It's really funny to me that someone could get excessively
| sucked into tinkering with and "nerding out" over Macs, the
| desktop/laptop platform that's by far the _least_ inclined
| toward that. Usually stories like this start on Windows or
| Linux and end up on Macs precisely to minimize time &
| brain space lost to tinkering and esoteric platform
| knowledge just to keep things basically working OK, as the
| appeal of that sort of thing wears off.
|
| I don't mean that in a bad way! It's just one of those
| "huh, so many different experiences out there, who'da thunk
| it" things.
| whatshisface wrote:
| Not every problem can be solved manually. There are many
| businesses where the technology itself is the valuable thing,
| not just glue between humans doing all the work. "Don't write
| code" is smart when the code could be replaced by a person and
| a spreadsheet but that is not always the case.
|
| Examples include circuit board layout programs, finite element
| modeling, any engineered hardware product, entertainment (like
| computer games), or anything other than pure business, really.
| kareemm wrote:
| > Examples include circuit board layout programs, finite
| element modeling, any engineered hardware product,
| entertainment (like computer games), or anything other than
| pure business, really.
|
| "Don't write code" really means "prototype first for your
| potential users". So if your code won't have users/customers,
| then write away. But hardware and entertainment can
| absolutely have low-fi cheap prototypes.
|
| This approach is designed to elicit learnings to make a
| better product that's cheaper and faster to build. Of course
| you can write code first, but my experience suggests that
| that's a slower and more expensive approach.
| blowski wrote:
| To further your point, there is always a risk that some
| assumption you're making will turn out to be wrong. You
| should build the product only when the risk of not building
| it is greater than the risk of your assumptions being
| wrong.
| 0xdeadbeefbabe wrote:
| Users fixate on low-fi even if you tell them it's a
| prototype. Talk about a blocking bug.
| [deleted]
| Abishek_Muthian wrote:
| I agree. Earlier in my entrepreneurial journey I've spent a
| year building a product without validating it properly or
| validating it with biases (validating it with like minded
| people) only to find that not many wanted it when the product
| was released[1].
|
| Tangentially, recently this motivated me to build a platform
| for validating problems by making people post their problems
| and even validate startup ideas as solutions to those
| problems[2].
|
| [1]https://hitstartup.com/startup-ideas-vs-problems/
|
| [2]https://needgap.com
| Jasp3r wrote:
| Read the second paragraph he is talking about:
|
| > Ok, now -- what language was it written in? Which editor did
| you use? Use any open source libraries?
|
| > In the best way? How long did it take to run the build? Was
| it easy to debug?
|
| > Was it as memory efficient as it could have been?
|
| > Were you building it on a really slick machine? What was your
| keyboard set up?
|
| This article is about your improving your life as engineer,
| questioning your technical way of working is how you grow, but
| not always the way forward. Search this article for the words
| "company", "business", "startup" or "customers" and you will
| find 0 hits.
| jasonlotito wrote:
| This is not what the article is talking about in the slightest.
| The choices are:
|
| 1) working on tooling 2) building the product
|
| Of the two, which do you prioritize?
|
| The article makes the case for #2.
|
| That's it. Nothing you say contradicts what the article is
| saying, nor does it add to what the article is saying.
| tuldia wrote:
| It saddens me to see people growing a business and having to make
| tradeoffs due to hosting costs or trying to catch up with new
| tech.
|
| My (opinionated) take on this if you are just starting a new
| business: 0. Lay your foundation on something
| that is battle tested and well supported.
| Rent/buy a real computer (dedicated/root server), not cloud.
| Use software that is already included in major/stable GNU/Linux
| distributions. 1. Build your stuff. Get used
| to writing things. Beware tech news.
| rooam-dev wrote:
| Imho it's far from "just". The advice works for short lifespan
| products and/or single "builder" and/or when requirements don't
| change much.
|
| Getting the product fast out there is not enough. It's more
| important to make changes fast, to allow product be shaped and
| built further.
|
| It should be a balance (see "golden goose" tale). If you have a
| team of "builders", than tooling becomes even more important, 1
| person's extra effort will make others more efficient.
|
| "Just build the product" sound like a consultant motto that ships
| by specifications, but only that. You could "just" build a
| product that needs 1 hour to be deployed.
|
| Edit: I would say a better advice to "builders" would be just
| focus on the scope, it's very easy to get exited and overengineer
| things.
| pgm8705 wrote:
| I couldn't agree more. For 5 years prior to 2019, I would
| routinely get excited about building a project. Despite being an
| experienced Rails developer, I'd spend hours upon hours
| researching and learning all the latest and greatest tools and
| languages. I did not even get close to shipping an MVP in all
| those years. In 2019 I realized enough was enough and started
| building my ideas with Rails. It has been a joy and I'm close to
| having my 2nd project up and running.
| iliomadfear wrote:
| At the risk of seening facile, the "just" the title resulted in
| my being hostile to the article. But, to try to be fair, I read
| it.
|
| After completing the toughest gig of my professional life to
| date, "just build the product" as an instruction/conclusion feels
| both useful and flip.
|
| In my head, I have an idea for a product. Sod all money in it.
| But as useful tool for something I care about, the "just build
| it" mentality fits.
|
| However, in the roof-over-head world of making something useful
| for an enterprise customer "just build it" feels trite.
|
| I went in to as a software consultant/developer to a fairly non
| IT literate organisation and was tasked to deliver to their
| specs. The big and costly challenge was to discover the product.
| To understand and challenge their specs, see the gaps, refine the
| UX and deliver. In my naivety, I thought the the customer would
| be receptive to this approach. Turns out they were - but only
| because I shouldered the cost of doing so. A massive learning
| experience for me. The customer got a product that exceeded their
| expectations - but, for a fixed price gig, commercially a failure
| for me.
|
| I wouldn't change my willingness to jump in this time around, but
| I won't repeat it - and would now walk away early from a customer
| that thought they had the solution all figured out (as opposed to
| having the problem figured out). In this circumstance "Just build
| the product" feels trite and self-indulgent. Clarity on what to
| build is hard earned. And the opportunities that iterative
| development affords to a a software development organisation are
| a hard sell to one whose core expertise lies outside IT. Possibly
| a failure on my part, certainly room for improvement on my part.
| overcast wrote:
| Sure, if the product is something you don't intend to make a
| business out of. Otherwise, you should be doing your homework
| ahead of time, and seeing if this is something people are
| actually in need of. Most ventures I've worked on have been
| derived from the immediate needs that I found not being covered
| in my day to day life from others.
| marknadal wrote:
| I love this quote from it:
|
| "Build features, not toolchains."
|
| https://www.urbandictionary.com/define.php?term=webpack
| foxfired wrote:
| There's been a change in sentiment here. Just build the Product
| is still neat advice that needs to be repeated. Sometimes we get
| too caught up with the plan, perfectititis, and only ever
| fantasize about building it.
|
| In contrast, the more experience you get building products, the
| more your repertoire of problems grows. You start to realize that
| the code is only one part of the problem. Interacting with people
| is what makes or breaks your product. So, you plan better, you
| meet the right people to talk to, you figure out when to
| outsource and when to do things yourself. You take more time to
| build stuff.
|
| But, you can't do any of that unless you first build a product.
| tristanstcyr wrote:
| Rather facile advice.
|
| As a software engineer, it's your responsibility to build the
| product according to the requirements. Sometimes that means it
| needs to be built it quick because it's likely to have a short
| life, or it needs to land quickly to market. Sometimes, you need
| to get things right, otherwise you end with an insurmountable
| amount of technical debt and a business that grinds to a halt.
|
| Given this, you should make the analysis to understand the tools
| that you need. If that means learning, then so be it. Maybe you
| can keep going with superficial knowledge. Or, perhaps you need
| to find an expert, that's fine too.
|
| As for growing in your technical knowledge, that should be agreed
| upon with your employer or whoever is paying for the work. If you
| find that you work somewhere that doesn't allow you to learn then
| perhaps it's not the right place to be.
|
| Think like a professional.
| gfodor wrote:
| The problem is it's extremely hard or often impossible to know
| what are good choices before you've started building the
| product. This, combined with the fact that software is highly
| malleable, should lead one to highly prefer a bias towards
| action vs analysis. It's not a hard rule, but it's much more
| common for people to fail due to analysis paralysis than due to
| poor technology choices. If you are able to get any form of
| traction, opportunities open up to expand resources and time
| that will be needed to adjust technologies. It won't
| necessarily be fun, but when going through such an experience I
| believe more often than not engineers have hindsight bias, not
| a true recognition that early choices were made objectively
| incorrect given the knowledge at the time.
| hinkley wrote:
| I've seen plenty of project grind to a halt from bad
| decisions and high pain thresholds. I think you'll find and
| even mix in the overanalysis crowd of white tower thinkers
| and people exhibiting allergic reactions. If you are seeing
| more of the latter I have two theories. One, those people
| gatekeepe projects, so once bitten twice shy (ie they
| accumulate and add friction) or two, you are looking at more
| early phase startups than me. A seed phase startup locked in
| analysis never sees my resume, so I don't see how often that
| happens.
|
| But the trick is to start with the new Reversible decisions.
|
| We don't always know which are the reversible decisions, but
| many of the irreversible ones are obvious. For some reason
| developers always focus on the irreversible one. We reason
| that we have to get this right, because it's very important.
| And if it's important, we should do it first.
|
| No. No. No.
|
| If instead you start tackling all the reversible decisions
| first, you can make those choices quickly (because changing
| them is cheap, spending a lot of energy on making them is a
| waste of time and capital). Start building something. Get
| momentum. Get the team and ideas to gel.
|
| When you start to know what you're doing, then tackle the
| irreversible decisions one at a time.
|
| But typically, everyone wants to Decide. And they want _you_
| to decide on short notice, right now, like some sort of used
| car salesman. If we don't tolerate this from others, why do
| we tolerate it from our teammates?
|
| Deciding for the sake of deciding is not productivity. It's
| painting a floor when you haven't identified a workable plan
| yet. There are always at least four corners, and rarely more
| than two doors. The odds are not in your favor.
| shantly wrote:
| I'm having a hard time following what you mean. Could you
| give some examples of an irreversible decision that can be
| deferred in favor of some other specific reversible one(s)?
| hinkley wrote:
| Interesting. You know, I would've sworn I had a pat
| answer to this question, but it turned out I had to think
| about a little bit.
|
| They say that some of the most rewarding interactions for
| teachers are the ones where they learn something, not jus
| the student. Every once in a while I get an example of
| that in real life.
|
| So what are some examples? Programming language is often
| difficult to change. This is sometimes listed as a pro
| for microservices. Because I get to change my mind for
| every new area of the app, which makes it cheaper to
| reverse directions.
|
| The most obvious answers that I have are load balancers
| and external caches. I shouldn't have a big knockdown
| drag out argument over haproxy vs nginx. Now, a load
| balancer is almost a given. It's possible that someday in
| the future, someone will invent an SMP machine with 256
| cores that gets some economy of scale by running a whole
| website on two machines. It's easier to reduce the number
| of machines behind a load balancer than it is to add a
| load balancer to a mature product. So put one in, but
| don't fight about which one. We don't know if we need
| haproxy features, or if we want paid support from nginx
| now. Just flip a coin and move on.
|
| Similarly, external caches are usually easier to turn off
| than internal ones. With internal caches, people start to
| pass around IDs instead of objects, assuming object
| lookup is "free". It becomes integral to the information
| architecture. A rat's nest of lazy and duplicate lookups.
| External caches are cheap but never free. Access tends to
| leave bigger footprints in the code. And there's some
| small hope that you can get a direct lookup down to a
| small multiple of the cache lookup time if it really
| becomes necessary.
|
| Database architecture is another big one, for certain
| dimensions. Going with Oracle is hard to take back. MySQL
| vs Postgres is smaller. KV store versus MVCC SQL database
| is also harder. For a prototype it might make sense to
| pick one that is obviously a placeholder, like SQLite,
| until you know what your customer's needs really are. Do
| they need audit trails? Are they addicted to graphs?
| Multitenant security? On and on. You can stave off fights
| with SQLite because it's effectively a promise to revisit
| this later.
| gfodor wrote:
| If you thread this up to the product-level, opportunities
| abound. For example, instead of storing data for a
| feature, see if you can get half the feature without the
| data storage. Or, if a certain feature is going to
| require a major shift in the way the UI looks or works,
| perhaps there's a way to blend in a v1 to the existing
| metaphors that can be replaced later. Etc
| cs02rm0 wrote:
| _As a software engineer, it 's your responsibility to build the
| product according to the requirements._
|
| Ah, the solid, dependable base that is the requirements!
|
| I'd question the reason to wait. Shove it out the door so you
| can learn. I say that _because_ I 'm a professional and I've
| seen many projects fail before seeing a single user. I've never
| seen insurmountable technical debt grind a business to a halt.
| Not once.
| onebot wrote:
| The point isn't "just start coding". The point is to focus on the
| product(customer development and all) and not the
| tools/technologies to build the product. I have seen many more
| focused on the latest and greatest stack instead of using the
| tools they are already good at.
| hinkley wrote:
| As with most things in our field, the opposite of a bad thing
| is also a bad thing.
|
| When stuff is new, people have a higher tolerance for
| repetitive, error prone things. For tedium. For bullshit. But
| over time a portion of your team will lose patience. Their
| allergy to bullshit will return. These are many of the same
| people who pull off productivity gains, hard performance fixes,
| who fix hard to find bugs. Who prevent whole classes of bugs.
| If they don't get to fix the things that bother them, they will
| go somewhere where they can.
|
| What will be left are the status quo people. If you don't have
| your project in a good shape when that happens, it never will
| be. You will have achieved mediocrity.
|
| If things are good and the allergic people are still pushing?
| At some point it's appropriate to move on. Just make sure you
| know for sure things are good and aren't just listening to
| feedback from the status quo folks.
| jimbokun wrote:
| > If you don't have your project in a good shape when that
| happens, it never will be. You will have achieved mediocrity.
|
| But most times the alternative is not mediocrity, but no
| viable product at all.
| ChrisMarshallNY wrote:
| I've been working this way for thirty years. In fact, I can't
| remember ever working on something that wasn't designed to ship.
|
| Even my test harnesses are fully-qualified applications.
|
| I remember a manager once saying "The number one feature of this
| product is 'SHIP.'"
|
| Because of the nature of the companies in which I've worked, we
| always worked backwards from "SHIP."
| randomsearch wrote:
| This is exactly the opposite advice I would give to anyone
| starting a company - avoid building software at all costs.
| draw_down wrote:
| That's not what TFA is talking about. This is not lean startup
| advice.
|
| It is advice for engineers to focus on the utility of the thing
| they are making for other people, rather than focus on the
| toolchain that allows them to build the thing.
| aphextron wrote:
| The best code is no code.
| tylerrobinson wrote:
| I don't think the article is saying "just start coding", it's
| saying "when you code, use what you know instead of working on
| the tooling".
| volument wrote:
| Haha. I see what you mean. Lack of market is the #1 killer of a
| startup.
| pezo1919 wrote:
| Yes and no.
|
| I'd say if you have a set of features and a toolchain which
| enables you to build them then ofc go for it.
|
| However that's not my usual experience with any of my projects
| even personal ones.
|
| The thing is I don't know what I'm going to build, in the
| contrary, I am aware it will take several iterations to figure it
| out. Because of that I have to check out what is "out there" in
| the ecosystem to make sure I can change directions sometimes if I
| want to. I want to maximize my freedom in that niche. Because of
| that every time I have some additional information about the
| whole project (in which features come and go) it's an option to
| step back and reevulate existing possible solutions in my mind
| and go do some further research when necessary.
|
| My experience is when parts are not thought out in a project then
| they will slow the entire workflow down over and over again.
|
| Just build or just not to build: I think this is a wrong
| question. When start to build & how/what to research are much
| better I think - and with real examples its much more useful I
| think.
|
| Eg.: I'm totally done with relational and document databases. To
| me it seems both suck hard so lately I am investigating graph
| dbs. No, I won't start a new project until stupid rigid schemas /
| migration problems / schemaless weaknesses (dupe) won't just go
| away.
|
| Maintaining old shit is enough for me I really don't want a new
| broken system as technical/real life debt.
|
| Ofc you can go out and build pages with jquery which do generate
| tons of money for you, but others will be able to do the same
| when they've figured stuff out. What then?
| johnvega wrote:
| It is great if it succeeds and useful, but if not, it's usually a
| great learning experience.
| flagpack wrote:
| Thanks, just what I needed. Your use of those two paragraphs was
| very effective.
| davnicwil wrote:
| Thank you - and really glad it was useful
| ozim wrote:
| Yar, funny those people who comment "no never build the product
| first, do marketing and find if there are customers for it",
| don't read the page.
|
| "davnicwil" is, guess what -> "Open source" "Freelancing"
| "Consulting"-> motto "I turn ideas into products"
|
| He is just trying to sell his services to people who want to
| build the product, and guess what he advises them to do that, and
| that is his page. This is not some holy grail advice, get some
| context and step back people.
|
| Ok I know everyone is reading only headlines here anyway...
| vjeux wrote:
| If you are interested in going further down the pit, you may want
| to consider joining an infrastructure team at a bigger company.
| This way you are able to use your skills at the bottom of the pit
| to enable many more people to build the product faster.
| draw_down wrote:
| One consequence of this is that you're by definition far away
| from the product and the end user. This is not necessarily a
| direct problem, but it is worth considering. For example, a
| coworker has been hacking away on our infrastructure pieces for
| forever. Their work is in support of our large React app, but
| this person basically never writes actual React code.
|
| It's possible to end up in a situation where your skills and
| abilities become "purpose-fit" to the situation you're in,
| which can be tricky to transfer elsewhere. Whereas most
| organizations can appreciate the work and abilities of a
| "product engineer", or whatever they call it. So there is some
| risk to this approach.
| XCSme wrote:
| This rings a bell or two. After spending years of creating
| projects with Webpack and wasting tens of hours on configuration,
| I just started my new project with parcel, where I just run
| "parcel index.html" and I'm done. I had fun configuring all the
| stuff before, but now I just need to get the work done.
| quantum_state wrote:
| AAbundant past examples have shown if a business "just build the
| product", it will soon does not need to build any product any
| longer ... since it will be belly up :-(
___________________________________________________________________
(page generated 2020-01-03 23:00 UTC)