mojo - kn

MojoTech, like most companies, has the concept of a Project Lead. Initially, I wasn't sure what to expect when I took on my role as Project Lead, so I'm writing this post to shed a little light on the responsibilities and expectations of the role, as I approach them. Typically my morning and afternoon look the same, so to avoid redundancies, we’ll take a look at a typical morning schedule.

Newton's first law of motion states:

Here at MojoTech, we are lucky to have several engineers who have used Ruby on Rails from very early on in its history. For me personally, the year 2016 will mark a full decade of using Rails for application development. In total, we have four Mojos who were using Rails in those very early days, and while we now use many different programming languages and tools, the early days of MojoTech were established as a "Rails shop".

Lately, I've been working on Satellite, an open-source monitoring solution for Mesos clusters. It has become clear that Satellite needs to be easier to install and configure, and that we may need to change the very nature of its configuration files. This has led me think about software configuration in general, and particularly about which styles work best in which situations.

Welcome back to my 3-part review of Bertrand Meyer's, Agile! The Good, the Hype and the Ugly. As a quick refresher, last time, in part 2, I took a look at what Meyer considers “hyped” about agile methods. In part 1, I took a look at Meyer’s take on what’s ugly about agile. This week I’ll take a look at what Meyer considers both good and brilliant about agile. Meyer considers these agile practices the cream of the crop and thinks they’ve done a lot for software development. I don’t see much difference in utility between what Meyer considers ‘Good’ and ‘Brilliant’, but I’ll review them as he’s categorized these practices.

Welcome back to my three-part review of Bertrand Meyer's, Agile! The Good, the Hype and the Ugly. As a quick refresher, last time I took a look at what Meyer considers "ugly" about agile methods. This week I’ll take a look at what Meyer considers "hyped" about agile. Meyer considers these agile practices neither helpful nor hurtful to building impactful products. While many of these practices can be beneficial, they need to be examined on a project-by-project basis to ensure that they are applied appropriately.

At MojoTech, we constantly evaluate our processes and tools to improve the way we build great products for our clients. We follow the Agile Methodology but employ its various techniques dependent on the needs of an individual project. Opinions regarding these techniques can vary immensely, so I, along with my fellow Product Managers, recently read Bertrand Meyer's, Agile! The Good, the Hype and the Ugly. Our aim was to brush up on our agile best practices and make certain we were avoiding its pitfalls. As a team we agreed with many of Meyer’s points, but we also found that in many cases, "it depends". I’ll take you through a three-part series of blog posts assessing Meyer’s points on "the good," "the hype," "the ugly," (and as a bonus, "the brilliant"), and whether our team agrees, disagrees, or feels it’s contingent upon the situation and context.

As developers we're tasked to take a problem specified in the fuzzy language of human interaction and translate it into a representation that can be understood by a machine. To do that we have to simulate the machine in our heads, and manually trace every possible path of execution. The number of execution paths grows at every branch point in the code, and there are often many different ways to branch an execution path. This results in a search space that can very rapidly grow to be unmanageable when trying to figure out which code path is being followed.

Who's afraid of big bad technical debt?

Every conscientious software engineer knows about technical debt. Lots of us learned the hard and painful way that deferred refactors and sloppy code can and will come back to bite you eventually. Since we don't like being bitten, especially by our own code, we learn to hate that nasty technical debt. All manner of evil gets blamed on it, and we avoid it like the plague. Like some digital bogeyman, we speak its name to scare junior developers into writing good code.

Businesses are always looking for an easy “silver bullet” to success.