This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (12)
- # beginners (159)
- # boot (3)
- # calva (41)
- # cider (48)
- # clara (2)
- # clj-kondo (8)
- # cljdoc (8)
- # clojure (70)
- # clojure-dev (10)
- # clojure-europe (2)
- # clojure-losangeles (1)
- # clojure-nl (12)
- # clojure-spec (7)
- # clojure-uk (63)
- # clojurescript (24)
- # cursive (24)
- # datomic (22)
- # expound (17)
- # figwheel (1)
- # fulcro (176)
- # graphql (23)
- # jobs (9)
- # jobs-discuss (56)
- # kaocha (1)
- # mount (3)
- # nyc (1)
- # off-topic (91)
- # onyx (3)
- # overtone (4)
- # pathom (3)
- # pedestal (1)
- # re-frame (11)
- # reitit (19)
- # ring (8)
- # shadow-cljs (16)
- # test-check (5)
- # testing (2)
- # tools-deps (20)
- # vim (9)
For those who’ve worked in start-up environments, I’ve got a question for you. I’m told “Well, early-stage companies ship crap software - that’s just how the game goes. Once they’ve landed funding, then they can slow down, rearchitect the system, write tests, write a CI/CD pipeline, etc.“. This seems bonkers to me. How common is this? Is it really the norm, or are there startups that “measure twice, cut once”?
@d4hines I would expect there are some startups that do indeed Do. It. Right. but I've seen a lot of startups that build a proof of concept as fast as possible to pitch to VCs and that ultimately becomes the first production version of their system 😞
A lot of startups have very toxic work environments in many ways. You couldn't pay me enough to work in a startup again!
Tests and CI aren't that useful in my opinion. At least I've not missed them on clojure projects where they're missing and we are rushing for the early parts of a project.
but CI is still nice. If it’s my project they’re there from day 1 just because it’s easier to set that stuff up with sensible defaults when your project is tiny
Generally there's a false dichotomy between agility and testing, paricularly between those who aren't proficient in the latter I've added test suites where missing at various startups (size 3 to 50) and never it was a rejected proposal or delayed the roadmap. So I'd try gradual introduction of best practices. If they are flat-out rejected I'd run away since that CTO is likely to make my job miserable in more than one way
Being quick to market makes sense for a start-up, but so is a plan to eventually make it sustainable.
but then again standard advice for startups is “do things that don’t scale”, including founders fulfilling orders, humans augmenting “AI” and so on
the thinking is, most of the time you don’t even know whether people will buy your thing so there’s no point building an actual thing until you get proof
I don’t think there’s anything wrong with building a prototype / proof of concept, as long as the founders are aware it’s a PoC and it will need to be rewritten from the ground up
except the concept of a prototype doesn’t seem to exist in the agile world, and so people are left polishing a turd, and understandably angry about it.
I would say it depend on your ops experience (I feel ci / cd are using wrong all the time by people, personally I call all this things
ops). If you are able to create good deploying and testing environment you are doing this. If not you are not doing this on the beginning.
I am doing both Dev in Clojure and Ops, because I like it and I see it as whole picture. With Ops experience I can solve things simple and easy on different level when I can’t do it simple on Dev level.
From my experience most of Dev don’t have high Ops experience, so complex tools for Ops can make issues for them
And it is really not about startups only, it is easy to do it wrong in all sizes of companies 😉
Summarising up: Personally I am doing Ops for all my Dev work, but I feel comfortable with it
Answering your question: I would depend Ops things on early stage on team experience
I’ve grown two Clojure teams from back of the napkin ideas into self sufficient businesses. This my 2 cents. The priorities and incentives for a startup and established business are drastically different. In a startup you’re basically trying to survive — looking for the next client, trying to raise that next round, etc. You’re doing your best to make every dollar count and in most tech startups, the most expensive thing is development. It’s more valuable to ship something imperfect now than a perfect something later. It’s a tradeoff between cost and time. Of which, startups don’t have much of either.
That being said, being in a startup doesn’t preclude you from writing quality software
Re: quality - if I were to do another startup, I would put more emphasis on quality test suites. Functional, integration, e2e, etc.
My problem with tests at early stages is that you're still exploring the domain. You can't test anything to do with the domain, because it will change constantly.
This is hard to discuss without clear timeliness of the stages we are all comparing though.
This is another topic, detailed unit tests don’t make too much sense, we want to test general ideas and functionality and critical flow
A timeline that makes sense in my mind: before customers pay for it, it should have tests.
I would go even further and say there is a lot of things which we can really test only on production
I’m not discussing the merits of unit vs functional vs integration vs generative vs whatever testing.
But I think about tests also like about documentation of the system, when writhing them. To show how to use system in code
Funny thing, right now I'm working on adding extra test coverage for something I merged 1 week ago i.e you can defer specific coverage of specific instances, but create a ticket for it, having it all under control The opposite (e.g. 3 months x n developers' work at 0% coverage) very likely has no way back
Personally I found myself not able to fully test things which depend on third party systems. Just because there is no way to query this system without consequence and not able to make safe clone of it.
And never trust documentation of third party system,. If they write in doc they return X it means they only write it in the doc, but system can return in corner cases Y
From my observation there is also another important topic which everybody miss. Psychology! We have different personalities. There are people who are good for making something new, but weak to finish the job to the end including optimisation for things like tests. On the other hand have people who do very optimised things and done the job, but if there is something what don’t exist already and they have to start something new there are much slower, because care about too much details. There are also different personalities like people who deliver weak code on deadline, but they care about time. And more…
I think this psychology topic is very important and it is very important to understand personalities in your team
If you put wrong guy to the job he will fail not only because of experience, but also about his personality