Have you ever considered a service or suite of services and thought, “that looks like a ball of yarn.”
There is a tendency amongst those of us who write software for a living to consider systems that are not understood as garbage. Often, this suspicion of poorly understood systems turns out to be unwarranted. What look like obtuse decisions made for no apparent reason turn out to have solid foundation in rationality.
There has been a dearth of posts to this site. Part of the reason for this is that I got busy playing Overwatch by Blizzard. The underlying mechanics of the game are team based and players must work together to achieve success. Failures in the game are often due to players not working together effectively. These sorts of failures can have lessons for teams working on projects in a professional capacity; today we’ll look at a couple of team failure modes and consider ways they can be rectified.
Today’s post is short essay concerning the value of development led quality. There are no code examples or short tips for things in this post. I hope you enjoy.
Today’s post will cover a couple different approaches to transfering techinical knowledge of a software system between individuals or teams. There are often transfers of ownership as a software product progresses from conception to feature development to ongoing maintainence. Effective knowledge transfers between owning individuals or teams help to ensure that ongoing development of a product is not totally stalled whenever ownership chagnes
Apache CouchDB 2.0 was recently released and has some compelling features for those looking for clustered document oriented databases. In today’s post I want to share a few of things that I’ve learned on how to use CouchDB’s new features and how to avoid some new user mistakes that we made along the way.
Today’s post will go over some of the reasons for why I switched my personal blog back to being generated via a static generation tool from Wordpress. I have previously written about not using static content tools , we’ll look at some of the things that have changed in the last couple years with regard to complaints I had in 2014.
I enjoy running my own blog at codinginthetrenches.com because I am a technologist that likes to write. Unfortunately, sometimes my interests as a technologist get the better of my interests as a writer. This last week my competitive interests resulted in my blog being visually broken for several days. Furthermore, the competition has resulted in a few select articles being mis-formatted and visually broken for much longer than a week.
Today’s post is about what I’ll be doing to avoid these problems and how they can apply to your own writing platform.
We often think about best practices while developing software. Sometimes it is also instructive to contemplate what not to do when writing software. Today’s post covers some logic in AngularJS services which should be avoided save for rare exceptions.
Developing new software involves resolving a frequently unknown quantity of problems of unknown complexity. Even when working on existing projects, new initiatives and features can contain a unknown total amount of complexity. While being appealing modern product management methods, scrum and other related methodologies focus on relative estimation which has limitations when starting brand new work. Today’s post looks at some of our limitations when it comes to estimation and what is implied by those limits.