This is the third and final article in a series of three about my experiences creating the JavaScript framework TuxedoJS. I'm using the same heading from one article to the next, so the next little bit is a summary of the series of posts and links to the other articles.

Now that my classmates and I have finished the initial release of our first framework, I thought it would be good to explain how TuxedoJS came into existence. In an effort to make it a little bit easier to handle writing about this topic I've decided that instead of writing one massive post, instead I'll break this into a series on the process that will be composed of several posts. The current plan is to write the following posts:

1. Why Make a Framework on React and Flux?
2. Identifying Pain Points in React and Flux, and Determining Initial TuxedoJS Feature List
3. Taking TuxedoJS From Feature List to Feature Complete Framework

Early Decisions

At the very beginning of our project we knew that we were going to be working on a large product and we were going to be working closely for an extended period. With those things in mind we agreed to a set of standards and expectations that we would all hold each other accountable to throughout the project. The following list, in no particular order, were the expectations and standards:

1. All code must be tested and documented to be merged.
2. All code and commit messages must adhere to our style guide.
3. Never merge your own PR, no matter how small or simple.
4. If you're stuck let the team know and someone can help out.
5. We're all in this together.

Setting up these standards and expectations early was tremendously useful, as the entire team was on the same page from the get go. Testing and documenting your code as you write it may seem extremely intuitive to everyone, yet I know that if I don't do it as I go that it will fall by the wayside. By doing this from the start, we were able to perform a major refactor of our code immediately prior to our release with an extremely high level of confidence that everything had been updated properly.

There were several major benefits to everyone following the same code and commit styles. One of those being that when code is written in the same style it is easier to read and review that code quickly. While reviewing pull requests I found that if it followed our style guide I was able to quickly dive in and review the core aspects, where as if it didn't follow our style, my eyes were immediately drawn to the parts of code that looked different and it took me longer to get to the crux of the pull request. Additionally our code looks like it was written by one person, which I think makes it easier to read.

The last three things were great for me in particular, as I knew that I always had a team around me. Having the reassurance that if I ever got stuck or lost motivation, that the team was there to support me and hold me accountable and that was immensely useful. At the same time I was there in the same capacity for my teammates. The advantage of laying these expectations out is that everyone has the same set of information instead of assuming that everyone has the same knowledge.

Workflow Process

Overall I'd say that our project used a relatively simple workflow. We would hold a stand-up meeting at least once a day. During which we would report where we were on whatever feature we were working on currently. If we had merged in a pull request, the originator would explain what had been added and answer any questions. Doing this allowed everyone on the team to know what was going on with the framework.

As I mentioned previously, we used waffle.io to assist us in handling our GitHub issues. Waffle was extremely useful during a stand-up, as we were able to quickly see where features were in the development process: what features were waiting, what features were ready to be worked on, what was in progress, and what had been accomplished. We were also able to add features to the project as they were discovered and close out things that were not feasible or no longer made sense.

Lessons Learned

Throughout the course of working on TuxedoJS I learned and incredible amount of valuable lessons. Here are some of the lessons that stood out the most to me.

• Document Driven Development is a thing.

With TuxedoJS we started with a list of features that we wanted to implement and then we started writing code and documenting it as we went. We found out part way through that another approach was to do document driven development, where you write the documents first that define your API, and then you write code to support the documentation. The process that we followed worked for us, yet I certainly see how using document driven development in future projects would be advantageous.

• Requiring tests to be written prior to any code being merged proved invaluable.

As I mentioned earlier, writing tests as we developed our code proved to be invaluable. Immediately prior to our initial release I performed a large refactor of our code base and our test coverage allowed me to do that with confidence. While it takes an investment of time to write tests as you develop, that investment will likely be repaid several times over throughout a projects life-cycle.

• Having an established code style guide makes it easier to review pull requests.

While it may seem like a small thing, having a consistent and agreed upon code style that everyone follows makes reviewing code reviews easier. Not having to waste mental energy parsing everyone's unique style allowed me to focus on reviewing code and completing those reviews more quickly.

• Pair programming was amazing when I was stuck on something, needed another set of eyes on a problem, or if I had just lost my motivation that day.

I went into this earlier, so I'll keep this brief. Pair programming was extremely beneficial for me throughout the development of TuxedoJS. It gave me access to a secondary brain when I was stuck or needed another perspective and it helped motivate and energize me if I slowed down over the course of a day.

• Getting outside eyes on a project can help an incredible amount.

When you work on a project you enter a little silo with your teammates and while you understand everything that is going on, the outside world has no idea what's going on in your silo, so it's very intelligent to get outside one or several outside perspectives. People that aren't directly involved in your project will not have the same attachment to features or design that you will, so they can help you determine what is working, what is not, and what will work with some tweaks.

• I can either improve software or develop my own solution.

I now have confidence in myself that if I find parts of software, tools, or frameworks that are painful or difficult to work with, I can make that experience better for myself and others. While working on projects, I now keep a record of difficult or non-intuitive aspects of software, that way I have a list of future projects to work on!

• I can make a framework!

Prior to this project, I don't believe I ever thought I would make a framework. There are any number of reasons that I believed this to be the case. Anything from what could I write a framework on to I don't know how to do that. Having finished the initial release of TuxedoJS, I can see that my inner critic had a powerful voice filled with doubt and second guessing. Fortunately we elected to take on a large and difficult task and discovered that we are indeed very capable of implementing a framework.

Final Thoughts

Implementing TuxedoJS is the best and most amazing experience that I've had so far while developing software. The fact that we were able to implement everything that we wanted and more into TuxedoJS was ridiculously rewarding. All of my teammates gave it everything they had throughout the entire process and I think that it shows throughout our product. When we finally published the initial release I was extremely proud of what we had accomplished thus far.

Thank you for taking the time to read about my experiences while developing TuxedoJS. The project has been extremely rewarding thus far and I see it being rewarding well into the future. If you have any thoughts or questions on my experiences feel free to leave a comment!