What are the high-level criteria that guide and govern our best practices at P'unk Avenue

[kerrygilbert]

Before we can "canonize" practices into the READMEs of this repo, we'd like to establish a set of criteria that we can use to measure potential BPs...

These should be high-level principals that aren't necessarily specific to any patterns or technologies. This list would live on the homepage of the README and serve as our commandments.

Some Good Examples:

1. We write code that can be easily maintained and understood by all members of the development and support teams.
2. We believe in solutions and technologies that are pragmatic and not overly-engineered (not using Gulp for the sake of Gulp FOR EXAMPLE)
3. We build things in a way that best leverages Apostrophe's tools and and doesn't conflict with patterns already established by Apostrophe (This is the CMS we design and build for ourselves. Don't fight it.)

   Other ideas:

   • We write code that adheres to W3C standards
   • We build websites that comply with WCAG A accessibility standards (AA and AAA should be something we're prepared to implement when requested by a client)
   • Mobile and responsive should not be an afterthought (we implement these features as we go as opposed to applying them as a band-aid at the end of a project)

...Are these good? What are other ideas? I'd like to have a tentative list drafted by next week. Please send feedback and ideas @agilbert @boutell @stuartromanek @kyjoya @austinstarin @grdunn @bgantick.

[boutell]

I like this list. I think some space for growth and improvement in our technology choices is important, but it shouldn't be allowed to eat the schedule and budget of a project.

[austinstarin]

I don't mean to throw a book at this answer but the Pragmatic Programmer might be a good reference point to continue this conversation (I believe there's a copy in the P'unk library if you haven't read it):

https://pragprog.com/book/tpp/the-pragmatic-programmer

Here's a quick reference guide as well:

http://www.ccs.neu.edu/home/lieber/courses/csg110/sp08/Pragmatic%20Quick%20Reference.htm

[agilbert]

Great call, Austin. Pragmatic Programmer is great, I could definitely use a refresher on it (been several years) and those who haven't read it would benefit from doing so!

[kerrygilbert]

Good recommendation... The quick ref is a great cliffs notes. It would be fun to read/discuss some sections of this book as a group someday. I haven't read it since I worked at Cipher Prime.

There's a bunch of points in the second link that could potentially be mined for ideas, but these all feel too granular... Plus, almost everything on this list should be applied to all projects, but I'll admit many of them are not sustainable within the budget/timeline constraints we're often faced with.

Remember, we're establishing best practices for people who work on client projects at P'unk Ave. We should try to prioritize values that exist within those realities to make things easier and more productive for our team (and better for our clients, of course).

[austinstarin]

Definitely hear you! Was thinking that it would be a good starting point (it's what comes to mind when I think of high level principles that drive my work) — definitely not suggesting a wholesale adoption of all the points that Hunt and Thomas list.

[boutell]

Sure. I like most of Pragmatic Programmer a lot. The idea of creating DSLs (Domain Specific Languages) was more useful in a literal sense when the book was written. Today we're working in languages high-level enough that it doesn't really make sense to invent programming languages, almost ever; but Apostrophe's module pattern, app.js, moog, etc. all add up to a DSL in spirit.

On Thu, Oct 27, 2016 at 4:09 PM, Austin Starin notifications@github.com wrote:

Definitely hear you! Was thinking that it would be a good starting point (it's what comes to mind when I think of high level principles that drive my work) — definitely not suggesting a wholesale adoption of all the points that Hunt and Thomas list.

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/punkave/best-practices/issues/13#issuecomment-256754768, or mute the thread https://github.com/notifications/unsubscribe-auth/AAB9ffbR_46vfdwp4dPsvGCamV0i_f0Kks5q4QTggaJpZM4Kiek1 .

THOMAS BOUTELL, SUPPORT LEAD P'UNK AVENUE | (215) 755-1330 | punkave.com

[austinstarin]

This is a great look too. It's a list of high level design principles that Jeremy Keith put together from various sources: https://principles.adactio.com/

[boutell]

Austin's link nudges me to mention a few things that should be on our list:

• We never make things worse for the sake of making them cool; when we diverge from a well-established convention, we accept full responsibility for addressing everything we're giving up. For instance, it is not acceptable to break SEO, accessibility or sharing features that would have worked just fine without that AJAX call.
• We always think about how a website will work in a year. We're not generally concerned about "webscale," but we are definitely concerned about questions like: "does the pagination work? What happens when they have 1,000 blog posts in the index? Will the speed be reasonable then? Will it crush mobile phones then? Can they tell what year this article was posted in? Will they need to add a link in this field — if so, why are we making it a textarea rather than rich text?"