Ask HN: What do non-technical founders need to know about software dev?

41 点作者 aosaigh超过 1 年前

I myself am a freelance developer and I regularly work with non-technical founders to bring their ideas to life.I feel like matching the expectations of your client or partner is crucial in the beginning of a project.It’s important to lay out the groundwork, process & technologies while not including the tedious details. Communication is key etc etcI’m keen to uncover my blind spots and see what other HNers with experience in similar circumstances think is most important when working with non technical business owners and founders

28 条评论

tmountain超过 1 年前

Code is a liability. Anything you choose to build requires continuous maintenance and care. Fixing things in the design stage is 100x easier than in production. Vigorously debate whether you should build something at all. If you can get something off the shelf that is well maintained and well supported, that’s usually the best option. Old and boring technology is the safe bet. Don’t get distracted by shiny objects. Continually ask yourself what your customers want, and validate those assumptions. If you’re not 100% sure, it doesn’t get built until you are.

评论 #37272864 未加载

评论 #37272796 未加载

评论 #37281700 未加载

评论 #37272975 未加载

评论 #37273154 未加载

评论 #37272626 未加载

oneplane超过 1 年前

Software is open-ended in almost all practical scenarios. This means that it is never 'finished' or 'fixed', always prone to new vulnerabilities, performance issues and deprecations. There is no set-and-forget.This then impacts everything else, from requirements to budgeting, from compliance to performance and everything in between.So when you manage expectations, that would impact how you'd define something as 'done', and how you'd include contingency planning for example.More often than not, because it is never really visible to the layperson, time and money stops flowing and software just 'sits there' until something goes really wrong. The responsibility of that lies with the business owner, not with the software engineering or technical departments (when money and time are not allocated by the business part, that is).In a way, you'd need to be a marketeer, a PR person, a communications expert, do sales and be a financial risk advisor just to set the right expectations when time and money are traded for software. This is also something that almost never works out in reality, so that's a bummer.

评论 #37272846 未加载

Frost1x超过 1 年前

Many non-technical people like to look at things that already exist and interpolate or extrapolate. "Well Facebook does this", "well I can buy GTA 5 on a shelf at Walmart for $60 (or something)", "people do this, I see it" and they have no idea of the level of effort and investment behind these things, they assume because it exists and is affordable you could erect something competitive or some similar feature set for marginal cost.Under managing expectations, you need to have a little heart on heart and try to bring some reality to the ideas. People don't come up with ideas in a vacuum, they look at inspiration from examples, connect things, add/remove them, and mutate them.I've also worked with a lot of engineering disciplines outside of software and people think because something is virtual in nature (it is "just software") it's significantly easier or cheaper than doing things with real physical capital. That isn't always the case. They also assume it's significantly easier in general, it's not civil engineering and you're not building bridges. Sure, you're not, and software isn't as commited as concrete in some senses but that doesn't mean erecting it or changing it is free, as designing and altering design for a bridge isn't free either. In the past year I've has someone handwave a theoretical issue as "it's just math" to some underpinning needed that has essentially remained an unsolved problem in mathematics for 60+ years...I could go on... but the most important aspect is to talk through the ideas and try to find any empirical evidence you can to get people to understand the level of complexity, scale, and amount of capital groups commited to make something they think is trivial and only need a handful of SWEs and a few months to throw together as if it were a PowerPoint that can handwave reality away.

评论 #37273258 未加载

pizlonator超过 1 年前

- Software is usually more complex than you expect it to be.- Software complexity is proportional to the number of engineers working on it. Hiring more people will increase complexity. So, hire as few engineers as you can get away with to solve the problem.- There will be bugs. It’s inevitable. Blaming people will only make things worse. It’s possible to mitigate the problem with process (and that process assumes that there will be more bugs but streamlines how you resolve them).- Programming languages, tech stacks, and other areas of engineer preference largely don’t matter. Let engineers pick what they want. Remember that the good solutions are often free and have stupid sounding names.

评论 #37273031 未加载

评论 #37273241 未加载

评论 #37272997 未加载

physicsguy超过 1 年前

SaaS isn’t consultancy and jumping through a million hoops for a single customer probably isn’t going to work when it comes to selling the software.

评论 #37272556 未加载

评论 #37272763 未加载

评论 #37272817 未加载

评论 #37272528 未加载

dsugarman超过 1 年前

Bugs happen, it doesn't mean incompetence. letting your team know the impact of the bugs in production is helpful but breathing over their necks or throwing a tantrum when you have an impactful bug is not. Tell the team, make sure they're working on it and give them space to breathe.Push for move fast and be understanding when things break, especially early on.Every feature you add will add a ton of future maintenance, so don't do custom work for every new customer, it will bury you over time. Do proper customer development and include your technical co-founder when you want to consider a new feature.

whateveracct超过 1 年前

You need to maintain some slack to be able to react to change quickly. Driving your developers at max capacity will bite you. You want them to have some spare energy and time.Also, have some indirection between "what I want" and "how to build it." Let software people manage the software.My last non-technical cofounder did neither of these things. He always wanted to-the-hour estimates, granular checklists so he could "see progress," and he would prescribe implementation and write pseudo-logic instead of focusing on business need.Part of that last part was he was kind of a control freak. If things didn't turn out as he expected, he would complain and it would take a whole debate to convince him the minutiae he wanted weren't worth the cost.I left that startup several years in. Well before we really got anywhere. That's the other thing about software developers. You are managing them and telling them what to do, but turnover of the wrong people at the wrong time hurts.

anyfactor超过 1 年前

I worked as a freelance Python dev and worked on developing a few MVPs.- There is no one-time investment. Some clients think they only need to pay once, and it will work indefinitely. However, things break all the time, and clients sometimes forget that tech companies have software developers with regular salaries to continuously fix things.- Adding features is not easy; devs must get accustomed to providing an overview of the investment required to bring a feature to life- Contractors are not partners. Contractors bring the client's idea to life, they are not responsible for the business success.- Contractors are temporary; documentation is forever. Client's need to understand the value of good documentation and onboarding material. They need to compensate you for that. When you conclude the contract, client's require these documents to onboard the next person. Developers are not wizards; they need guidance to comprehend someone else's code.- There are numerous variable factors, such as hosting, version updates, policies, etc., that regularly cause things to break. Software is not written in stone; metaphorically, it is written on a long sheet of paper with the other end on fire.- Get used to drawing diagrams and explainer docs. You need to break down your ideas and process to the client. They need to know why they are paying for, or else they might chose a riskier proxy variable "the financial success of the project".- Get super good at writing contracts. Most of my fuckups happened due to me not having a good contract.- Free consultancy to attract a client is good and all, but if you are required to "birth an idea from the client" charge an initial consultancy fee.Last but not least, all these points are good and all, but sometimes when projects are far and in between, you might have to compromise on some of them. That is just the sad truth.

olalonde超过 1 年前

If you work in the same office, telling them about "the zone" is a must: <a href="https://softwareengineering.stackexchange.com/questions/46252/how-to-explain-a-layperson-why-a-developer-should-not-be-interrupted-while-neck" rel="nofollow noreferrer">https://softwareengineering.stackexchange.com/questions/4625...</a>

lebuffon超过 1 年前

I recommend reading Fred Brook's Mythical Man Month. It's old but still has relevance and has been republished this century.My favourite: "It takes nine months to have a baby no matter how many women you put on the job."His failure on the OS for the IBM 360 mainframe led him to believe software is like that. It's worth the read.

评论 #37272943 未加载

23B1超过 1 年前

I'm an experienced nontechnical cofounder. Good advice in this thread so far but I wanted to weigh in with a verrrry clichéd pointer: that a lot of friction around expectation management, program management, resource management, etc. gets a hell of a lot easier if you have rapport and can be candid with each other.Here's how a conversation – that could turn into a huge argument – can go if you're candid with each other. I chose this conversation because it happens all the time and if handled incorrectly can be nuclear.CEO: "Board says we need to launch by the 1st."CTO: "That's an unreasonable timeline given our current resources – but here's the ways we COULD hit that deadline."CEO: "Okay, so either you need a) more time, b) a deeper bench, or c) expectations adjusted with the board."Note how they both provide possible solutions to the conundrum they're in, and neither is about who said what or who fucked up planning or whatever. Solution oriented, we're both in this together, here's how we get out of it. The only way you get to that pragmatic, candid level of conversation is if you both trust each other and know that the mission is bigger than either of you.When you have a small team, those after-work drinks or lunchtime xbox sessions or that #dankmemes Slack channel become super important in building that rapport and subsequent trust.

kriro超过 1 年前

Maybe an unpopular opinion but I think it's reasonable to ask a non-technical founder in a software startup to learn to program (basics) by going through one of the online courses and roughly understand the stack. So if the product is based on Django...either go through a Python tutorial or even better a Django one. Yes it will be strange and uncomfortable but I think it's a good idea to have this level of understanding. Understand how your technology works in general terms but specific to your product. For example if it's a web app with an API, roughly understand what happens when someone surfs to the website (request-response model, how do REST APIs work, what is a database and why is it used).Similarly, I'd expect the technical co-founder to stay up to date on non-technical issues and bed-time read relevant marketing (or design) books and get some exposure to these things. Even more so then the reverse I'd expect a technical co-founder to jump in and do non-technical (sales) tasks if required.Or in other words, roughly speaking...the technical co-founder should be able to make sales and the non-technical co-founder should be able to talk about the product to technical people without sounding like a fool.

replyifuagree超过 1 年前

Most people have no appreciation for just how much work it takes to actually finish software.This is because unfinished software and finished software often look/feel identical to non-technicals right up until customers discover the true state of the software and disengage.If the above is true, then figuring out true customer needs is critically important because creating software that no customer wants is one of the fastest ways to burn money.

ducharmdev超过 1 年前

On a higher level, software development is a process of converting unknowns to knowns. We can't estimate or act upon what we don't know; as we uncover details, we can more accurately gauge level of effort and what the best solution is for the problem at hand.If they're nontechnical, they may not care about how it's done at all, but they will care about timelines. They may have agreements with others that depend on the product, or may have stakeholders they need to communicate with.As developers we usually focus on our direct communication with the business owner, but I think it's helpful to imagine the second order communications that will result from how we communicate progress on our technical solutions.For example, if we convey confidence to get a certain piece done by x date, the founder may in turn pass on that confidence to shareholders. But if we later backtrack after realizing that it will be a bigger lift than expected, the founder may have to walk back those expectations.

notacoward超过 1 年前

A successful team is a team, with roles, not a random collection. Obviously any project will involve different technical specialties. Some people are better at early design and core coding, others at filling out that skeleton, still others at debugging or testing or things that enable either. Your most productive programmer is very unlikely to be great at leadership or even mentoring - which are themselves not quite the same thing. You need people who are enthusiastic about every new technology and people who would rather stick with the tried and true. You need all sorts of balance along with the psychological safety that allows people to be different and have disagreements without losing trust in one another. I've seen "superstar" teams absolutely fail, and "journeyman" teams absolutely fly, strongly correlated with whether management understood what "team" means.

Waterluvian超过 1 年前

Almost all complexity is hidden under the surface. If X was easy, and Y looks like X, that does not mean Y will be easy.

ghomem超过 1 年前

My recommendations:* avoid hype trains: it is a trap* avoid complexity unless there is business based justification: it is another trap* understand that every thing you build needs maintenance* understand that the integrations you build for something you don't build also need maintenance* software has many layers: choose where to be disruptive and where to be conservative* avoid superficial cultural assumptions like "smart good junior people that hug trees will do wonders": you need a couple of pragmatic engineers to impose common sense in the operations* avoid bogus metrics like "I deployed to production 20 times last month" and embrace sound metrics like "we delivered the features on time with few or none bugs found in production"* foster an engineering culture: ensure people understand context, tradeofs and relevant metrics

评论 #37273216 未加载

Ologn超过 1 年前

Some lessons on software development were learned a long time ago, but have not really sunk in everywhere.Fred Brooks was a project manager on IBM's project to launch the System/360 from 1961 to 1964. He took on the responsibility to do the operating system software for the System/360 - OS/360. There were problems during the project of writing the OS software and lessons learned. Ultimately the System/360 (and OS/360) launch was successful, and the product sold well.Brooks wrote a book on the experience in 1975 called "The Mythical Man Month". One of the things the book covers is how a software development project can differ from other kinds of projects, so business should have different expectations.One lesson is if a project is running late, adding additional programmers to the project tends to make the project even later.Another is the second-system effect - that a follow-up to a successful project can be an attempt to reinvent the wheel, which is too complex and with too many features (just keeping to the operating system example, Windows Vista and Hurd could be seen as two examples of this).Another is to "design one to throw away, you will any how". Inevitably for any good product, the software will be refactored or even rewritten.Some ideas from the book are almost universally accepted. Some are debated, such as whether it is good to have a technical team divided into a leader/architect/"surgeon" and assistants (something Brooks favored) or whether other approaches work. If you read over past comments on this forum, or read other programmers and PM's thoughts, the book is considered to have had a lot of valuable lessons for people over the past half century or so. However, I know for certain that despite it generally being considered a source of a lot of wisdom on software development, many of the lessons are ignored nowadays in companies large and small.One of the main takeaways though is 60 years ago, Brooks realized software development projects worked differently than other kinds of projects. He put his lessons into a digestible form in his book almost 48 years ago. But even half a century later, many businesses large and small blithely ignore a lot of these lessons.

gorbachev超过 1 年前

If you're doing something novel, it is more or less impossible to estimate when it will be done. Progress will usually be slow, with bursts of extreme productivity after a breakthrough.

Jemm超过 1 年前

Without a sales and marketing budget your product is doomed. There are very few exceptions and very few companies with the funds to burn on a product that is not marketed.

trebligdivad超过 1 年前

* Not all software dev is the same; if you're building something new then that's much more risky. * Track the risk as well as any dates - a section that still has the same date but has suddenly got less certain needs watching. * You split it into separate parts - good; now make sure you leave plenty of time for integration and testing as you bring the parts together. Do it regularly. It always goes wrong.

muzani超过 1 年前

Cost increases exponentially with complexity. Things like React/reactive programming are there to slow the slope down, but don't aim to make a "superapp" or "platform" unless you really have to. There's a reason why startups do so well vs companies like Google who hire the best engineers on the market - they just focus on a really narrow scope.

TheCapeGreek超过 1 年前

You touched on an important one: managing expectations. Secondarily, this also means being a good communicator with non-technical people; i.e. being able to translate technical concepts (and their importance on the work being done) in ways the stakeholders will understand, and help to adjust any ideas they have over the work ("why isn't this easy?").

gremlinsinc超过 1 年前

I'm a senior full stack dev, freelancer. I'm switching to AI consulting and bot development and building sites using tools like framer because it feels like a lot of the time we over engineer things and the future is embracing AI especially for lead based business like real estate, insurance, home service pros, etc.

jcutrell超过 1 年前

Everything is easier and harder than you think it will be.It’s easier because humans tend to overcomplicate matters, when usually the simplest thing will probably suffice until you have serious demand for something more complicated.It’s harder because once you decide to do something simple, humans have a strong impulse to overestimate what they can do in a day, a week, or a month. I call this the sandwich principle.Making a sandwich is easy - you probably know the steps by heart. So, how long would it take to make 500 sandwiches?Using your gut, you might not think an answer like 2 hours is off. But if you do the math, you realize you’re probably way off. This is because the simplicity of the task fools us into thinking it will also go quickly.Focus hardcore on outcomes, and define your metrics of success early (and redefine them over time). Hand these things to your product owners and engineers, and ask them to deliver a new version of value as often as possible. Listen to your tech leaders when they start talking about rebuilding and refactoring, and ask them if there’s a way to do it Little by little.Take everything in small increments, even if you have big vision. You can still do it little by little, and you’ll learn more and get the value curve going much faster that way.

heyjamesknight超过 1 年前

“Build it custom,” should always be the last resort, when off the shelf tools have failed. Don’t be penny wise and pound foolish: $200/mo for some tool or service may sound like a lot at first, but that’s 1-2 hours of developer time.

e9超过 1 年前

For this topic I recommend book called Shipping Greatness. The book has different sections for non technical people on how to work with engineers and how to work with designers.

Terretta超过 1 年前

A few things both sides often overlook:… … …For Non-Technical Founders:- Cost, Time, Value: Software isn’t built overnight. Both the timeline and budget are usually underestimated. Key is to control focus on priorities. The MoSCoW method of classifying work as Must/Should/Could/Won't plus a Kanban of ToDo/Doing/Done with a parking lot for Someday/Maybe items is simple but beats most other project management methods. For the iron triangle of Need, Budget, Timeframe, control RoE by fixing team size to the appropriate burn, and adjust throughput by adjusting focus on need.- Scalability: While a quick MVP (Minimum Viable Product) is important, consider whether the tech stack used will allow for growth.- Quality Matters: Bad code can work in the short term but can lead to expensive fixes later. It’s like building a house on a shaky foundation.- Updates and Maintenance: Software isn’t a ‘build and forget’ entity. It needs regular updates and potentially costly maintenance.… … …For Technical Founders:- Business Goals: Keep in sight why you’re building what you’re building. Tech is a means to an end, not the end itself. Your user has a job to be done. Enable it and get out of their way.- Speak the Language: Get good at translating technical jargon into plain English. Don’t assume the non-tech founder understands your lingo.- Flexibility: Non-tech founders may change course based on customer feedback. Be prepared to pivot without getting too attached to your code.- Validation: Always validate assumptions with real-world data. And wrap all systems with Observability. Think of it as Test Driven Ops. You can only safely "move fast and break things" if you know exactly what you're breaking when, so you can resolve it before your customers experience the breakage.… … …Mutual Blind Spots:- Minimum Desirable Product: Shipping that MVP is fun, but make sure someone will pay for what you’re making. A powerful technique is to survey customers for whether they can make do without the product. More than 40% need to say they can't operate without it.- Communication: Both parties usually think they are communicating enough. They’re usually not. Set regular check-ins.- Documentation: Neither side loves it, but both will need it. Clear documentation can prevent a lot of misunderstandings.- Roles and Boundaries: Establish who has the final say in what domain, and even more importantly, practice accountability. Power struggles can kill startups.- Prenup / Exit Strategy: Think about what happens if one of you wants to leave the startup. It’s not fun to consider, but essential.