Nuts & Bolts

For some developers, Business Requirement Documentation (BRD) is a cringe-worthy word.  For others, it is their everything.  I think that the appropriate place for BRDs lies somewhere in the middle.  

Business Requirement Documents are simply a list of things that need to be developed by a software engineer.  The business side of an organization will say “Hey, we need XYZ built for our customers!  Here is a document that has everything XYZ should do.”  The list of functionality for “XYZ” is marked down as “Acceptance Criteria” and the developer starts work on it.  When the developer is done creating the software, it is checked against the acceptance criteria to ensure that the delivered software meets all of the requirements that it was set out to do.  This is all how development works from a very high level.

To get more specific, there are two different types of development ideologies to achieve that process.  One type of ideology says that once a developer gets the requirements for the project, they start working on it and create the software to exactly meet the requirements of the BRD.  The flow looks like this:

Business owner gives the BRD to the development team.

Developer asks questions and clarifies the BRD.

Developer creates solution to address the functionality in BRD.

Developer gives functionality to business owner.

So far everything seems okay, the business owner got what they asked for, and the developer has accounted for what he was responsible for.  I’ll pause a moment here to give a real-life example of how this can go poorly.

Business owner John needs to add a new drop-down list to a form page in an application.  John builds out his business requirements to build the drop down with a tree menu. John does his best to try to explain what he wants in the BRD, then meets with the development team to go over the BRD and answer developer questions.  The developer builds a tree menu and a drop down, and lays them out in the application separately.  John didn’t explicitly say that the tree menu had to be inside the drop down.  The BRD had been perfectly adhered to, but the functionality was not what was being requested.  This resulted in another enhancement to be taken up in another development cycle to get to the desired functionality.  

Now on to the second development ideology.  Continuing with our example above, John decides he needs a new drop down with a tree menu inside of it.  Here’s how it would flow:

John approaches his dev team about the problem and they have a conversation.  

Together they come up with a different type of solution that uses swiping and panels, much like modern touch interfaces.  

After the solution is agreed on by the business owner and the dev team, the business owner creates the BRD to match what was discussed with the dev team.  

Developer gives functionality to business owner.

In this second scenario, John is happy because he got a better solution than what he was trying to accomplish, and the user is happy because the experience is much better.  The developer is happy because he got to have input on the design, and he got to use a new technique that he’s been wanting to try.  The relationship between business owner and developer is also better, since there is more coordination and better results.  In addition, when business owners are intimately involved with the development process, their business requirements get markedly better over time.  They also get better insight into the complexities of creating software, and gain knowledge of how platforms and systems work.

I’ve been in the bay area for about five years now, and I’ve been working at Yahoo for four of those.  During those four years, I’ve been a part of five different hack events, winning three of them, and becoming a finalist in the other two.

Corporate hack events are fun.  They are a way to show off your coding and innovation skills.  I’m sure non-technical people hear “hack” event and think that we’re trying to break into some system, at least that’s what my extended family thinks when I tell them about these events.  The hack events are much more open-ended than that.  For the purposes of these events, anything that is a technical innovation can be submitted.  Have a new way to show ads to users in a more non-intrusive way while increasing click-through rates?  That’s a guaranteed hack winner right there.  Did you find a major security flaw in one of the products published by the company?  Again, guaranteed hack winner with that submission.  The submissions can run the gamut between very cool innovative techniques and applications, to run-of-the-mill stuff that people do in their every day jobs.

So now that we’ve established what these hack events are, let’s talk about the process.  First, you come up with an innovative idea.  From there, most often you create some sort of proof-of-concept to prove your idea.  Once your idea is ready to submit, you apply to be considered for the hack event.  You write a few paragraphs, take some screen-shots, maybe take some video.  The upper echelon reviews all the submitted hacks and decides on a smaller number that will give live demos and presentations to the leadership team.  If you are selected,  you give your demo and answer any questions from the leadership team.  After your demo, the leadership decides which hacks win based on whatever criteria they want.  Prizes for these events are generally modest.  In the past, I’ve won iPads and Xboxes for these events.  This is, in my opinion, where the problems start with hack events.

Let’s say I’m an experienced software developer (it’s a stretch, I know).  Let’s also say that I have some great idea for the next big thing on the internet.  If I go the corporate “hack” route, here’s what would happen.  I spend a lot of time making a proof-of-concept, submit it, win my ~$500 prize, then it’s over.  If the idea really is a great one, someone will notice within the product groups and they will want to pursue it.  So now you transfer your idea over to the corporate product group, they implement it into production, and the company makes millions off of it.  You’re hailed as a hero for coming up with the idea, then you go back to your normal job -- the same one you had before.  Your creation is now out there in the wild, and it has nothing to do with you. 

The only other option is to spend a lot of time to get the proof-of-concept (same effort as above), try to get investors, and if everything goes well I have a company that I am leading and it is successful.  Then I become Mark Zuckerberg, except not like him at all.  Okay he’s a bad example (literally), but my point stands.

So one can see that it is much more advantageous to not give your best ideas to the corporate body.  Unless you’re a complete corporate shill, then that would probably be your best move.  But if your really looking out for your best interests, there’s not much benefit to just giving your idea away. 

In the recent past, I heard about this new programming language from Google, called “Go”.  Being an avid Counter-Strike player, I was a little put off because Valve named the latest version of CS, “Global Offensive”, or “GO” for short.  I couldn't possibly have two things named “Go” in my life, right?

Well I was wrong.  The Go programming language looks amazing.  Granted it is still young, but the potential for this language is immense.  Here’s the description of Go from their site:

Go is expressive, concise, clean, and efficient. Its concurrency mechanisms make it easy to write programs that get the most out of multicore and networked machines, while its novel type system enables flexible and modular program construction. Go compiles quickly to machine code yet has the convenience of garbage collection and the power of run-time reflection. It's a fast, statically typed, compiled language that feels like a dynamically typed, interpreted language.

They say a lot in that little summary.  Let’s break it down a little:

The first claim they make is to Go’s concurrency mechanisms.  In order to understand how big of a deal this really is, you need to understand how concurrency and multi-threaded applications work in a device with more than one processor.  Most applications out there have no performance benefits from running in a multi-core/multi-processor machine.  This is due to the fact that creating multi-threaded applications is so complex and difficult to do.  If you really don’t need to do multi-threading or concurrent processing, it is never worth the effort to build that into the application.  As a result, almost every single device or PC out there today has more than one processor, but almost none of the applications running on these devices can utilize that hardware.

Go is a modern language.  In modern times (such as these?) we shouldn't have such a barrier for creating multi-threaded applications.  Consumers want faster applications, and developers want their applications to be fast.  Granted, not every application needs to be multi-threaded.  If your application is linear in nature, adding concurrency can actually slow things down significantly. The engineers that built the Go language built concurrency into the language, and abstracted it away from the developer code.  This was a huge hurdle for them to overcome.  It’s a huge hurdle for anyone to overcome when trying to incorporate true concurrency into an application.  The software out there that has multi-threaded support today had to overcome these hurdles.  The team behind Go decided that they would do it once, for everyone, and build into the language itself.  Thank you team Go! 

Go also differs from many other languages by including the garbage collection process.  Those who are familiar with .NET languages such as C# will know exactly what garbage collection is and why it is important (and why you love and hate it).  In historical application development, the developer would have to manually control memory assignment.  This means that if you set a variable to a certain value, that value is stored in memory forever until you manually clean it up.  When you don’t clean up those values stored in memory, your application suffers from a memory leak.  Garbage collection works by keeping track of pointers to objects in memory.  When an object in memory is no longer referenced by some other object, the garbage collection process automatically removes that object from memory.  This does not mean that developers can simply ignore their resource usage, but it does help tremendously.  

While we’ve brought up .NET languages, let’s take it a step further.  Until very recently, .NET was a Microsoft technology that could only “officially” run on Windows devices.  Recently, Microsoft announced they would open source .NET, which will make it available to all platforms (as soon as the appropriate compilers are ready).  This is a great move by Microsoft and I applaud them for that.  The benefit of other languages over .NET has always been the cross-platform nature of them.  Applications written in C, C++, and Java can all be compiled and run on virtually any PC.  These languages are the standards for cross-platform development.  Go is also platform agnostic.  In addition, the traditional cross-platform languages are all very fast.  Initial testing of Go compilers show that Go can be close to as fast as the most mature C compilers.  There is a lot of room for Go compilers to mature, so I think the future is very promising from a performance standpoint. 

In conclusion, it’s been a long time since I’ve been so excited about a language.  It’s been out for a little while now, and I’m concerned that the adoption has been too slow.  I would hate to see a beautiful and efficient language such as this go the way of the Dodo.

A bit cliché I know, but I figured it was aptly suited since I am a software developer.  Anyway, hello internet!  I am Brad.  I am a husband, father of three (soon to be four), and I currently work for Yahoo as a software developer.

I'm not setting out a goal or even a topic for this blog.  I think it's cool to have topic oriented blogs, but I want this to be a little more random than that.  Maybe in 50 years my kids and (hopefully) grand-kids can look back at this blog and get a better sense of who I am and what my life was like waaaaay back in the old days.  Man I'm getting old...

Anyway, I'm going to try to not edit my posts very much; just let it be stream of thought.  My thought right now is that I think this is good enough for a first post!