This moved Here.
I wanted to share the details of a few conferences. I won’t be there, because I enjoy a life that’s mostly free of jetlag and commuting.
Guest Post by Brian Whipple, Marketing & Communications Manager at Cycligent.com.
There is a commonly known rule in business called the 80/20 Rule. Introduced as an economics rule to explore distribution of wealth, the 80/20 Rule has become a common business management principle, defined by this common “rule of thumb”:
80% of effects come from 20% of causes and 80% of results come from 20% of effort.
I often use the 80/20 rule to shed light on my own work habits, or to analyze cause and effect on results that I may have seen.
Recently, I read an older blog on the 80/20 rule and how it applies to software development. The author described how in software development, 80% of performance improvements are found by optimizing 20% of the code. Of course, this is not an exact science, but more of an estimation in order to self-evaluate where a developer spends time.
Through experience I have realized the fact that building a highly scalable, highly resilient, and highly available web application is extremely hard. Learning the ins and outs of AWS is a no small feat for even the most experienced of developers, let alone someone new to coding for the cloud.
As a result, we came up with an 80/20 rule of our own when discussing cloud development:
Only 20% of the features offered by AWS are utilized. The other 80% are extremely complex and are usually not implemented/maintained.
Due to the fact that building enterprise web apps is not always easy, the developers at our company, Cycligent, have found ways to optimize work for the best results. Here are a couple of ways that we have put the 80/20 rule into action:
We found that heavy client-side applications often suited best the applications that we were developing. When they were combined with Node.js and MongoDB on the backend, we reaped a lot of benefits. The line between a front-end developer and a back-end developer became much more blurred, making our developers more versatile. Impedance mismatch issues stemming from the client and server speaking different languages went away. This increased developer productivity due to less context switching between the frontend and backend code. In short, a small amount of time up front choosing good tools reaped a lot of benefits later.
We found that despite the promises of the cloud, it’s not always easy. Spending some time up front to abstract away as many of the complexities as possible make our developers much more productive, happier, and it lowered our defect rate. To give a specific example, when moving to the cloud and dealing with scaling our application and distributing the load across many servers, developers often got tripped up by when and how to properly communicate over a message bus. To alleviate that, we spent some time making it so the message routing was handled automatically behind the scenes. Developers only had to focus on the actual backend logic, instead of worrying about when and where the messages had to be exchanged, or that there was even a message bus at all.
While it is a struggle to build and maintain the highly available and distributed web applications, in our opinion the benefits of utilizing AWS for cloud development far outweigh the bad. We have implemented a few tools and processes to produce results in our company, and there are probably a lot more out there. We believe that in a lot of scenarios, finding tools and processes that line up with your company’s development process could lead to 80% of positive results.
Shameless Self Promotion
I am the Marketing & Communications manager with Cycligent. I contacted Julian Simpson because I respected the community of developers that have developed around influential blogs such as www.build-doctor.com and want to participate in contributing to the community. Also, I wanted share with you our new cloud platform that simplifies coding for the cloud. Go to www.Cycligent.com to learn more, and to sign up for a 30 day free trial.
If you can’t dispose of toxic waste (say, by burning it or launching it into space using surplus ICBM’s), then you probably need to contain it: stop innocents from stumbling across it, or stop the malicious from using it for malicious projects.
The same issues apply to your source tree. If you have Amazon Web Services credentials checked into a project on GitHub, that’s a toxic repo. You’ll want to contain to protect people from intentionally or unintentionally damaging the resources that can be accessed from the credentials.
One of the problems of having your own toxic waste dump, is that it’s very easy to add more waste to the pile. So that repo with a private key checked in might easily get an AWS credential, and a couple of months later, a raw database password.
Another is that sometimes, you might give the wrong people access.
What can you do about it?
Cleaning up some toxic waste yesterday was pretty good. That’s one less dirty secret.