Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

All the big companies have style guides, but protocols are harder to transplant because it's not reasonable for smaller companies to follow the same practices as big companies.

I wouldn't adopt more process overhead without a specific reason.

E.g. if you are having quality issues where R&D is shipping stuff before it's ready, then institute a more formal process of sign-off for a release so R&D needs approval from QA.

If you are having problems making builds repeatable, then start standardizing the environments with golden images, put everything in version control, etc.

If you have issues with licenses for third party code, a 3PP (Third party program) process with sign off from legal/other teams (security would be nice).

For each set of problems, there are processes designed to address those. You will also encounter less resistance when the process is a solution to a problem rather than adherence to a best practice. I also wouldn't try to adopt processes just to satisfy a general desire for more process, because there are costs to adopting process overhead, especially the cost of becoming a bit dumber, as an organization, each time you adopt a process to formalize what was previously a judgement call by some decision maker.



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: