
Ask HN: How to set up a tech stack/engineering practices for a new team? - chris11
I&#x27;m currently talking with a non-software tech startup that is currently hiring several developers to create a new product. And it sounds like they don&#x27;t really have explicit engineering practices or a tech stack. So if I ended up there I would be taking a lead role in defining practices and the tech stack. So I was wanting suggestions for several things.<p>What works well for git? I&#x27;m currently looking at gitlab and github but I haven&#x27;t really spent much time researching the differences. I don&#x27;t want to self-host the repo.<p>What project management apps would be useful? I&#x27;m wanting bug tracking, code reviews, and some kind of project management software. I used Visual Studio Team Services a couple years ago, and liked it, but I&#x27;m not attached to any one product.<p>Should I use continuous integretion, and what level of automated testing should I have? I&#x27;ve heard some complaints about running unit tests before any commit?<p>And should testing and code reviews be required for all commits? It&#x27;s a small startup so there might be some pushback. I don&#x27;t think they currently do any of that.<p>The dev team will probably be between 5 and 10 users right now. They are developing a windows desktop application and use AWS. So a setup that works with windows and linux would be good.<p>Does anyone have any other general suggestions?
======
codeonfire
Why don't you let the actual engineers decide on the engineering questions,
ffs? If you were making aircraft parts, would you ask the internet what
software you are going to decide for them to use? No you wouldn't even be
allowed to decide unless you were a veteran engineer with some licenses. "I
wanna make some wings. We are bringing on 10 aero engineers. what kind of
tools and metals should I set up? I heard swept wing is good to use, what are
your thoughts. I am leaning towards slide rules, but I heard RPN calculators
work well."

~~~
chris11
It's a small startup that hasn't been around for years. And it isn't a purely
software focused company. Most of the engineers will be joining soon to start
on this new product. They don't have a ton of engineers currently at the
company.

~~~
codeonfire
Then hire some engineers and let them decide. If they don't immediately know
what they want to use then you are not hiring engineers, you are hiring
wannabe's or college kids.

------
itamarst
As far as testing goes, there's no one correct answer. It depends on what your
goals are (and they'll probably change over time). E.g. if you're rewriting
all the code every other week unit tests won't help you much. And unit tests
won't catch many bugs. On the other hand unit tests can be extremely useful if
much of your code needs to be stable and consistent.

My current second-best explanation of how to choose testing based on goals is
written up here: [https://codewithoutrules.com/2017/03/26/why-how-test-
softwar...](https://codewithoutrules.com/2017/03/26/why-how-test-software/)

(My best explanation is currently a slide deck that will become the third
version of that post.)

------
quintes
Unless you're starting with zero.. Skills on the team? Current stack?

If nothing then I do this:

Git and stash. An agile approach, features and user stories. An agile board.
Vsts or rallydev Yes to continuous integration, deployment and automation.
Testing, unit tests first. A desktop application may have specific
technologies so .. depends.

Oh and code review, pull requests and I actually advise desk checks before
submitting PRs.

Regular demos of sprint work is essential

~~~
chris11
Those are good points. Tech stack can be anything as long as it runs on
windows.

What's the benefits of doing desk checks and code reviews?

~~~
jyounker
Code reviews are one of the best ways we've found to improve code quality. If
you're not familiar with it, then you should read up on it. There are plenty
of resources out there discussing code reviews (e.g.
[http://dl.acm.org/citation.cfm?id=2597076](http://dl.acm.org/citation.cfm?id=2597076)
or Steve McConnell's "Code Complete".)

Think about it this way. Code is as complicated writing. There is no
successful media organization in the world that would publish a book or
magazine without at least having one round of review, because hundreds of
years of practice has shown that review improves the final product
significantly. It's hubris to imagine that programmers are any better than
authors.

~~~
chris11
Oh, definitely. Code reviews are really valuable. I'm just curious about desk
checks in addition to code reviews.

Edit: that paper's pretty interesting. I haven't really thought about what
made good code reviews and what the causes of defects are.

------
afarrell
The #1 guiding principle for answering these questions that I've found is:
Start with "Why?".

Why are you writing any code at all?

Are you writing code to test a hypothesis and present the results of testing
that hypothesis to other people? If so, state that hypothesis explicitly,
build the minimum needed to test that hypothesis, and have a clear & concise
document (Dropbox Paper, README.md, etc) explaining how the code tests the
hypothesis.

Are you writing code to build a product that you plan to maintain for 5-10
years as you add features and support a larger user base? That implies that in
5 years, you are going to have some new junior engineer join the team who will
need to figure out how to navigate this codebase and modify it. They will have
a job to do and the UI they have to accomplish this job will consist of:

\- The codebase itself (including any tests)

\- The commit history of the codebase

\- Any diagrams or READMEs that were written alongside the codebase

\- The issue tracker

\- The other members of the team and their memories and communication habits.

Engineering practices and team habits matter because they mean that your more
junior engineers are able to much more quickly and confidently do projects to
solve evolving business needs as much or writing as many bugs. Think of both
your codebase and your project management tools as a UI whose users are the
engineering team trying to accomplish business needs. This talk is close to
the mindset I'm trying to convey:
[https://skillsmatter.com/skillscasts/10124-dylan-beattie-
the...](https://skillsmatter.com/skillscasts/10124-dylan-beattie-the-pursuit-
of-apiness-the-secret-to-happy-code)

Speaking personally, I find that automated testing is extremely useful for
moving quickly because it makes it easier for me to break a task down into
concrete pieces and to stay motivated by having constant positive feedback.
The cost of testing is that it takes a while to set up and is especially
difficult if you are not experienced in the toolset you are using. If you
don't have a good testing toolchain in place, then writing and running tests
is really painful and gets in the way of development

For this reason, it is tremendously useful to have testing infrastructure and
practices set up early on in a project by someone who is experienced with the
particular framework/language you are using. It is very difficult to introduce
tests after-the-fact.

The branching and code review process that I've found most useful is:

```

$ git checkout -b my-feature

# Write some code.

$ git add -p

$ git commit -m "do some small thing"

$ git status

$ git checkout file/that/has/leftover/edits/I/dont/want

# Repeat.

$ git rebase -i HEAD^^^^^

# re-order commits, edit commit messages, and squash some commits into

# larger logical blocks.

$ git checkout master

$ git pull origin master

$ git checkout my-feature

$ git rebase master

# It now looks like my-feature was developed off the tip of master

# And I've resolved any potential merge conficts.

$ git push origin my-feature -f

``` And then make a pull request to merge to master and tag someone to review.
CircleCI runs the full automated test suite on the PR. I've only run the few
tests that I've modified because they're the ones that relate to my PR. It
doesn't make sense to require passing tests for every commit because then you
can't write PRs where the tests fail. You might want to do this so you can
show someone a Work In Progress and ask for advice. It might make sense to run
a linter like rubocop on each commit, but only if each of the linter rules is
agreed-on by the team (just make a PR for it and have people +1 or -1).

If I need to make changes to the PR after pushing, I do so and then I rebase
on top of master again and `git push -f` the branch. Once tests pass and
someone +1s it, I'll merge to master and start on the next chunk of work in
the project. Note that on Github, if you tag someone for a review, and they
make a comment, you need to tag them again for your PR to show up in their
list of PRs-to-review.

Keep your work tightly in-sync with master. If there is a feature that I don't
want to go live, I use a feature flag to turn it off rather than keeping it
out-of-sync with master. Merging large changes that have gotten far out of
sync is hell.

For project management, try to be as lightweight as you can. We use a 1-page
markdown doc of "Here are good questions to ask to make sure you've understood
the scope of the problem and have talked to relevant stakeholders." and we
break the project up into trello cards that roughly correspond to PRs.

