Clojurians Log v2

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.

CD > CI

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

The test suites on our services save my day roughly once a week, but YMMV

Being quick to market makes sense for a start-up, but so is a plan to eventually make it sustainable.

I think it’s pretty common

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.

In world of containers and kubernetes it probably matter more than ever

but it is really hard to do it right, you need experience

If you will do it wrong, then it will be an issue instead of solution

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.

Personally I see huge benefit from it

But it took me a lot time to understand how to do it right

From my experience most of Dev don’t have high Ops experience, so complex tools for Ops can make issues for them

they don’t understand them and don’t want to learn them

so on the end you need whole spectrum of experience in team

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

Appreciate the input as always 🙏

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.

They allow you to move much quicker with more confidence

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.

especially when depend on third party systems

(Though I’d love to as a seperate topic0

But I think about tests also like about documentation of the system, when writhing them. To show how to use system in code

Description of custom business needs

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

For example if we want to fail all invoices which date is not in the current month

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.

So on the end you never know

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

so true tests are on production 🙂

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

Right people on right place

If you put wrong guy to the job he will fail not only because of experience, but also about his personality

team need to have mix of experience and personalities, but it is hard to achieve

people in team changing in time 😉

@d4hines ^ from another point of view, which we probably miss in discussion

That’s hard for me to grasp, seeing I’ve never done any management, but I’m sure you’re right @kwladyka, there must by psychological/social elements to it.