The non-technical side

Normally I can explain away a long absence by sheer laziness. Like anybody else, I slip into the grind and don't really feel like thinking about what I did at work once I slink home.  That's not the case this time, however.  At the time of my last post, I was at a very large retailer working on a sort of a "Skunkworks" project to improve the quality of a few aspects of its IT experience.  Though I was "technically" function in the role of a technical lead, I mainly developed software.  I was lucky enough to build up a highly democratic team, and with a project leader that didn't have much of an interest in all of the trappings of agile, we managed to get a very effective Kanban flow going and each did our turn in the leadership chair.  By this, I mean that the weighty "architecture" decisions and even ideas about how we could improve our day to day were completely democratized.  There wasn't an executive decision maker on the team, and things worked well.  Mind you, this was a team of very experienced, very agreeable developers, which isn't something that grows on trees.

Now, let's return to the "until recently" part of this post.  Though I was enjoying my stint at said large retailer, they decided to start going a different direction vis-a vis contractors.  I tested the waters and ended up finding an amazing opportunity right before the large retailer decided to extend me the extension I'd asked for.  Off I went to another, slightly less-large retailer.  In addition to being an altogether new technical challenge, the opportunity represented an extra set of responsibilities.  I spent a good deal of my time at my prior contract in a "people" role, figuring out how to make a team work better together, establishing effective procedure and sometimes, tearing down and restaffing teams.  I was tasked with doing a lot more of these "people" things at my new gig and a lot less straight "tech" stuff. 

Though I'm only a few weeks in, there are a few insights worth sharing about the transition and some of the things a technical person notices in this role.

You can't change everything overnight

I have to remind myself of this every day.  There are a lot of things that need fixing at my current gig.  From the lack of tests, to the waterfall-in-disguise "agile" process, to frequent micromanagement by developers.  These are all things that need to be fixed, but there's no better way to confuse, upset or anger your engineers than by shaking everything up at once.  Given, there probably are times where you could go "scorched earth" and roll an entire team over, but chances are you're going to need to maintain some existing software. And on that note...

Things are the way they are for a reason

Regardless of controlling one individual on a team may be, the status quo of a team is the result of a variety of factors.  If a team has delivered software, they've achieved some kind of success doing things the way they do.  As I mentioned above, I'm an advocate of the "unassigned and prioritized" backlog approach.  At my current gig, all tasks are pre-assigned during IPMs.  This made my blood boil at first (frankly, it still does) but I realized pretty quickly that the developers on the team weren't comfortable or capable of self-directing their work.  The only way the product team could get movement on tasks was to force them down to developers.

Leading by example goes a long way

This one is pretty simple.  If you want to earn a team's trust, the best way to do this is to be a part of the team.  When I was getting started, the expectation was that I was going to be a management "type," dictating terms and expressing my degrees of satisfaction from my ivory tower.  This has never really been my style.  I found that my team became a lot more comfortable with me when I embedded myself in the lab and did some programming.  Sadly, time is a precious commodity, and this it's sometimes difficult to find time to do this. 

There isn't one perfect way to do things

One thing I've noticed with my teams is that they do their best to "rigorously" follow the standard agile methodology.  Standups, user stories, iterations, IPMs, retros and so on.  Believe me, it's entirely possible to do these things and be completely non-agile.  If the team doesn't understand the purpose for the ceremony of agile, they're not going to glean the value of it.  When standups are becoming glorified status meetings, they should be cancelled.  When retros don't result in any tangible feedback and improvement, they should also be canned.  The whole purpose of agile is to be more effective in how work is completed.  Not every little part of it is going to work for everybody.  In fact, in my experience, I feel like trying to cram the trappings onto a team that doesn't understand them is a great way to get waterfall in disguise. 

Stay positive

There's always a light at the end of the tunnel.  Chances are, if you're not happy with the way things are going, you're not the only one.  Nobody wants to work around the clock, nobody wants to get beaten down by the business and similarly, nobody wants to be bored out of their minds.  If you start showing the right way to do things incrementally, chances are you can get some momentum in the right direction.  Also, it doesn't hurt to bring in some like-minded individuals. 

So you want to Mongo?

After a good 6 months of solid Mongo-ing, I think it's finally time to share some insights on the platform.  I can't remember if I shared my initial reasons for delving into Mongo, but the driving reason for moving on was a need to persist objects with a variety of nested properties.  Without exposing company secrets or boring you, it fit neatly into the problem we were trying to solve.  Imagine a standard table row with a varying degree of metadata underneath.  The standard way to do this in the SQL world is to have a secondary table that essentially serves as a key-value store (ironically, how some NoSQL databases store data).  Resulting access to the table would require a JOIN and things would get complicated when it was time to model your data out on the object/software end.  

After a lot of discussion amongst the team, we decided that the variable nature of the data (as well as the resulting oddness in data modeling) called for a change.  We had previously modeled our structure in PostgreSQL and the transition over to Mongo was pretty seamless.  The beauty of using Mongo for our specific platform was how it plugged into Spring.  Spring's Mongo support is absurdly easy and simple, and allowed us to store our metadata as a simple Map.  Mind you, there are most assuredly ways to do this with SQL databases as well, but Spring Mongo is perfect for this right out of the box. 

Anyway, let's get into some of the advantages and pitfalls of using Mongo and some reasons why you might want to consider it, and other reasons you may want to avoid it. 

Pro: Your data is best expressed as "documents," rather than "rows"

Mongo makes no qualms about being a "document store" rather than a traditional database.  What this means is that you store "collections" of JSON documents.  You can query these documents based upon facets of field values quite easily, with decent performance.  When you start to spread your data out across several collections, however, you're going to run into a wall.  The concept of a JOIN simply doesn't exist here, which leads us to...

Con: Your data structure changes frequently but your model can't

If you're going to use Mongo, you're going to need to be flexible on your modeling/software side.  Where SQL databases allow you to stitch new tables together with old tables via JOINs, this sort of thing can only be done in Mongo by doing discrete queries and stitching the data together in memory.  What you'll ultimately want to do is change the way your documents look, which often means subbing the type of data you store in specific fields -- this can be incredibly problematic for a system that doesn't allow for change at the same cadence and the database.  You should also be prepared to "sunset" some data as your structure changes. 

Pro: You don't like being a DBA

Mongo is incredibly easy to setup and administer.  Even doing things like sharding and replicating is a snap.  Additionally, Mongo's language of record is JavaScript, something that most of us are comfortable with.  There are a few domain-specific idiosyncrasies to learn, but beyond that, your confidence will build quickly.  You can also back your data up with ease.  I say this with a minor caveat: beware the "journal," especially if you're using things like database references.  Journal space can get absolutely enormous, and if your hard drive space is at a premium, this can bite you.

Con: You need to aggregate/summarize data

Don't be too alarmed.  Mongo has all of the summary functions you'd expect.  But prepare to have a bunch of JavaScript objects with nested objects expressing how you want to summarize your data.  If you're used to a nice, compact SQL statement followed by a GROUP BY, you're in for a rude awakening.  Once you start messing around with the aggregate(..) function, you'll gain a degree of familiarity.  This may or may not stop you from holding your nose as you write the code though.  

Pro: You aren't afraid of indexing for performance

When you're starting with Mongo on a small scale, you'll be suitably impressed with its performance.  Once you're dealing with tens or hundreds of millions of documents, you will notice a marked degradation in query performance.  The beauty of Mongo is that you can generally throw an index in and improve your performance to a spellbinding degree.  A protip is to use dex, a tool to automatically determine which fields could be indexed to increase your performance. 

Misc

There are a few tools you can use that will make your life incredibly easy.  I'm going to assume that you, like me, are a sane person and use a Mac in your development. 

Robomongo - My favorite Mongo querying tool.  The UI isn't much to look at, but it performs beautifully and is very query-friendly.  

MongoHub -  Another visual Mongo tool.  It brings nice UX to the table for certain operation but generally performs a bit more sluggishly and crashes in weird situations. 

Mongo Prefpane - A nice visual way to control your local MongoDB.  Another awesome aspect of Mongo is that it can be run locally with very little baggage.  You can also import and export data from a production or staging environment with ease.

Jumping into Swift/iOS

I'd say that one of the most compelling things for lifetime software developers like me is the realm of mobile development.  Most of us spend the majority of our waking hours staring into the screens of our beloved mobile devices.  To deliver an app that would penetrate this world would be a huge contribution to this world, a way to get some great acclaim, and if you're very lucky, make a few bucks along the way. 

I've only just gotten started, but I figured I could give a look into some of the pitfalls a beginner might encounter.  The first, and perhaps most important, thing to consider is that you need to cough up $99 for the privilege of writing code on an iDevice.  This seems a bit asinine, but I guess it is what it is.  Everybody wants a piece of the pie in the Apple world, and they can get away with charging for the privilege of developing code for their ecosystem. 

The next thing to consider is the nature of that ecosystem.  I'd say the biggest hurdle to getting me into iOS development was the language.  Objective-C was (is) an unwieldy leviathan loaded with strange details and syntactic qualms.  Once i made the jump to Java, I never found myself missing the pointers and explicit references of yore.  Every time I'd get started on an app, I'd start writing code and end up so frustrated that I'd just abandon my project and move onto something less productive but more gratifying.  

Swift has really changed all of that.  It looks a lot like JavaScript or Python and does away with the old fashioned ceremony that plagued Objective-C.  The really good news is that Apple is reportedly stepping away from Objective-C completely.  This means that the entire ecosystem will be accessed via a shiny new language.  

Not all of this is wine and roses, though.  My first move was to procure a copy of AppCode, JetBrains' answer to the pitfalls of writing Objective-C (and Swift).  As I've said many times in the past, JetBrains is really the premier shop when it comes to delivering tools that make programming pleasant.  The refactoring is fast and seamless, and the UI is very intuitive.  My past experience with XCode, which is the stock Apple IDE, was a lot less friendly than I'd like.  Much like Objective-C, it feels like something from the '90s.  That or there are just a lot of assumptions built in to tailor to a long-suffering development community.  Either way, I figured this would all change with the installation of AppCode. 

There's good news and bad news to this.  The good news is that AppCode works just like IntelliJ.  It's a great tool  as one would expect.  There's the full complement of refactoring tools and the lovely Darcula color theme.  It's also got an integrated UI composer, which is relatively new.  The good news, unfortunately, sort of ends there.  I'm guessing this is just a side-effect of Apple having a "closed" ecosystem, but AppCode can't function without XCode.  My initial take is that it taps into it for things like the UI composer and the other settings that it needs to operate.  

Where things start to get cool, however, is when you can have a barebones app running on your phone within seconds.  To get there, however, you have to register your device on Apple's developer site.  And then you need to refresh your XCode configuration.  Then you're good to go.  

I'll do my best to document my (mis)adventures as I get my first app out into the App Store.  The app is a simple thing that will allow bee-minded folks (like yours truly) to document where bees are seen feeding.  All it will really do is upload a photo and allow fellow bee-minded folk to view the sort of plants that bees seem to like.  It's not very sexy, but it's an idea. 

I do apologize for my long absence.  It's been a pretty eventful few months, filled with more Groovy shenanigans, a lot of fun with Mongo and some nodeJS too.  I'll try to get into some of those exciting topics soon. 

The Holidays are Over

Well, the holidays as we know them are officially over.  Somebody in Scottsdale is sweeping up red, white and blue confetti and many people are sobbing into their beers in Seattle.  With that, we enter the cold months of winter.  The months where football-obsessed software guys like me can finally achieve a sense of clarity and take up the pet projects that got no love during the nail-biting weekends. 

A few things to stay tuned for -- a look at the advantages of AngularJS and single-page applications (SPAs to the initiated).  

And (probably) more excitingly, a look at mobile development as I undertake a few apps that have been clanging around in my head for some months.  As well as a quick glance at the Swift language -- something that's actually got me excited about writing an app for iOS. 

Also, after a few months of working with a new team in my primary development endeavors, I have some thoughts on pragmatic automated testing... be it unit, integration, functional or otherwise.