cogitatio

In many young software companies, there isn’t an individual role for for software quality assurance.  The assumption is that between the development resources and the product stakeholder the software can be sufficiently tested to get you past the initial profitability hurdle, and through your first BETA and initial release.  In the very early days, this suffices.  It will get you to a point where the software is sufficiently stable that it can be used for the limited functionality contained in the first early releases.  That said, it is imperative that quality assurance becomes a stand alone role within the organization relatively shortly after the early stage releases of the software product.

Quality assurance is yet another area that is easy for executives outside of the development organization to write off as merely a “cost center” that doesn’t directly contribute to incoming revenue streams.  They couldn’t be more wrong.  It is rare for an organization to take the time to do an accurate assessment of exactly how much money bugs cost them.  I won’t go into the long litany of the costs associated with software defects, they can range from losing money on orders placed to losing customers due to software that doesn’t perform as specified.  Yet this doesn’t answer the question of why developers are poorly suited to acting in this role.

Unless you have a particularly small software organization, developers will have relatively specialized expertise in their niche of the software platform.  As the software platform evolves, this becomes more and more true.  And this is a good thing.  Noone can be an expert at everything (a topic for a post later this week).  You want your developers to become experts in their area, and not have to worry about being experts in other parts of the software platform – this produces the highest quality software product because people can focus on what they know and develop the best solution within that area.  The downside to this specialization is that developers may not have full knowledge of how changes in their area affect other parts of the application.  Beyond that, as developers are tasked with producing results, it’s not rare for developers to develop tunnel vision.  A development team member may be told that within the problem domain x, f(x) should result in y.  Then they try to produce this result given known or sane values within x.  And this is great, until a reasonable but unanticipated x value is given.  As the software complexity grows, these problems increase exponentially.

This is why the role of quality assurance engineer is absolutely crucial.  Their focus is on the consumer of the software, the customer.  They can look at the problem outside of the niche domain, and they can produce a better subset of test cases as a result – test cases that are likely to far exceed the scope of the test cases that the software developers would conceive of.  Further, they provide a valuable feedback loop into the development process that can take the software platform in new directions.  Software Quality Assurance is not a cost center, it is a cost saver.

I think I have finally got my blog fully integrated with Twitter, and through Twitter to LinkedIn and Facebook. With this iPhone app for posting, it should be full circle!

Required Software:

WordPress Twitter Tools Plugin (you will need to modify the settings such that the “New Blog Post” line is prefixed with #in, and you will need to modify the plugin code that sends the tweet to twitter to append \#fb to the tweet)

Facebook App – Selective Twitter Status (handles tweets with #fb at the end)

LinkedIn – enable the twitter to LinkedIn integration.

With all of that, you can write a blog post on WordPress, and an update with new post and the link to the post will be sent to LinkedIn and Facebook with twitter as the glue in the middle.  Given Twitter’s reliability issues, I may tire of this quickly, but for now, it works.

So, your business is growing, and your IT and development departments are screaming that the infrastructure won’t keep up with the increasing load being placed on both your human resources and your server infrastructure.  So, what do you do?

One approach to this problem is to say “I’ll deal with that when we get there”.  That is the worst way to deal with the issue because “when you get there” its already too late.  You sat on the ticking time bomb, and it will have already blown up.  OK, so just waiting and seeing won’t work, so what about saying “When we hit X point, then it will be time to invest (in new infrastructure or new human capital)”.  On its face, this seems like a logical way to approach the problem – set an objective metric, when you hit that metric, then you purchase.  So what’s wrong with that?  This manner of management presumes that you have a perfect crystal ball, that growth will not accelerate, that you can act quickly enough that you can fill your needs before the load crushes you.  And sometimes, you can do this.  IF you set your metrics such that they are reasonably ahead of the curve.  However, as a small to medium business, presuming that you can forecast the growth curve accurately enough to do this is a risky proposition.

So whats the best way to deal with this?  As a first step, you need be setup to review your needs regularly enough to make honest assessments of where you are now and where you will be in the future.  Your future window needs to be something that is actually predictable.  If your trigger point window is outside the time frame of your sales pipeline, well this is an indicator that your trigger metrics are too far out.  If this window is too far out, you are effectively saying “I’ll deal with that when we get there.”  As a second step, you need to trust the folks in the trenches to raise the flag that needs are not being met, and when they do  you need to listen carefully to those needs.  You need to have enough trust in the folks with their fingers on the pulse of your business to not resort to the knee jerk reaction of “We aren’t there yet.”

PS – sorry for the testing posts, I was trying to get the facebook and linked in integration going, and I think that is fully kosher now.

A fun, non business post will be forthcoming over the weekend, hopefully some good food blogging to do!

So, your software company has been in business for a few years, you have a relatively reliable revenue stream, and you can bring in new clients with relative ease.  Your software platform is stable enough that you can implement client projects relatively rapidly, but as technology changes and evolves, and as the business needs change, of course it leaves a few things to be desired.  Over enough time, it leaves quite a lot to be desired and may be on the verge of being unsustainable.  And here is where the conflict arises.  Sales is constantly selling new revenue generating projects that require development resources to implement.  Software engineering resources tell you that there simply isn’t enough time in the day to intelligently grow the software platform while at the same time managing the implementation of revenue generating projects that sales has sold.  So what do you do?

An intelligent manager will try to figure out if there is any way to either carve off some segment of development resources to work on maintaining and enhancing the software platform, or hiring in new resources to dedicate solely to the software platform itself.  But this is where the conflict arises.  Engineering resources dedicated solely to the software platform are by nature, NOT dedicated to directly implementing revenue generating client projects.  A short sighted executive sees such costs associated to maintaining and enhancing the software platform as merely a cost center – money spent with no direct tie to incoming revenue.  For the short sighted executive, this remains true whether you work with existing development resources or hire new development resources.  If you use existing development resources, meaningful work is hard to accomplish without some meaningful amount of time dedicated to it.  Software engineers generally require some good head space to wrap their brain around the problem and then dive in.  While it is possible to define tight enough sets of deliverables that quality software can be parceled out into nice discrete periods of time, without the buy in from sales and the executives that during this time, the development resources on this project will not be working on revenue generating projects, you have a recipe for failure.  This is even more true if you hire in dedicated resources to work on the software platform (The short sighted executive asks – “How can I justify their salaries based on THIS set of revenue projects?”).

There are really a few different parts to the solution to this issue.  Firstly, the executives need to understand that the software platform is the business.  If it rots on the vine, then the business rots too.  Secondly, instead of looking at the costs associated with building out and maintaining the software platform as a “cost center” there needs to be a paradigm shift – the executives need to look at the software platform as a pool of features, things that the business needs to make the sale and deliver for their clients.  Lastly, the business needs to allow the engineering resources to do their job and there needs to be an institutionalized notion of space.  If features required for the “Sale du Jour” are looked at as “features in the pool”, and engineering resources have the space to work on the pool of features rather than willy nilly on this client project or that, the world can be very different.  If these things happen, the software platform becomes a revenue engine, development resources can be used most efficiently, and everyone’s happy.  Then again, its a rare small company that can make the paradigm shift from “cost center” to “revenue engine” if this wasn’t an institutionalized notion at the outset.

In my nearly two decades of experience developing software, designing software, and managing software development teams, there is one style of management that is a sure indicator of something foul in Denmark – Command and Control.  As it turns out, a management style that was developed and adapted for use within military organizations, to ensure that in particularly chaotic and dangerous environments there is cohesion and a unitary vision, among a group of less educated team members, is particularly ill suited to managing a team of highly skilled, professional engineers, working in an office without the threat to life and limb.  In this type of environment, command and control is 1) devastating to morale, 2) inefficient to the extreme, and 3) is a self fulfilling prophecy for failure.  Yet time and again, I see this style of management employed within software development organizations, and this leads me to wonder why?

You know you are seeing a command and control management structure when 1) a unitary person, the commander, is responsible for breaking down big tasks into smaller sub tasks, and 2) the commander then parcels the sub tasks out to other people to work on, and 3) the commander monitors and dictates how the the other people execute on those sub tasks.  If you’ve worked a job, anywhere, surely you have had a manager who worked in this fashion.

I think that the reason why managers do this is quite simple.  They are being tasked with getting a job done.  Rather than trusting their team to break tasks up efficiently and collaborate, they trust themselves more.  The manager assumes that they were brought on to do just this – take big tasks and make their team work towards completing that big task, and who but “good ol me” is better at figuring out the component parts and their priorities?  Its a combination of ego, and a need to feel “in control”.  Sometimes this springs out of necessity to accomplish big things in as short a time period as possible and at other times it just grows within the organization as the organization grows.

Well, listen up – its a recipe for complete failure beyond a certain scale.  There are only so many things that a manager can micro manage, and the manager needs to be able to have a higher level picture for real growth and team collaboration.  If you are a manager of software engineers, ask yourself a few of these questions and think long and hard about where you see yourself in 2 years, rather than at the end of the next set of tasks.

1) Do you really want to hire folks who don’t ask you “Why?” – Because is not a good enough reason to do something, it wasn’t when your parents told you as a child, and its no better in the workplace.  Inherent in the “Because” answer is “Because I know better”.  Do you really know better?  And if you do know better, shouldn’t you be telling your team Why?

2) Would you want to hire someone you don’t trust to think critically?  Here’s where the trust comes in.  You need to hire the best, and you need to make sure that you trust the people who work for you to think about the big tasks and how they can be executed.  As your organization grows, and you move through the hierarchy, you will become less and less connected to the nuts and bolts of the technology.  Shouldn’t you trust those folks who are close to the technology to tell YOU what the most efficient way to approach the problem is?  And if you can’t trust them to do that, why did you hire them?

3) Do you really think you know better?  It is the ultimate in arrogance to think that you know more than the folks who you bring in.  You SHOULD bring in people who know MORE than you do about the technology.  You should trust them to bring value by thinking creatively, and applying the appropriate technology in the appropriate situation.

Command and Control management evidences a failure of trust.  Where that failure of trust exists, true collaboration cannot.  Where you can’t have true collaboration, you cannot leverage the power of a team.  And in that case, you have failed as a manager.

Well, it finally happened.  The web host I was using for the longest time to host my blog finally bit it, and years of blog data went with it.  Oh well, it’s a fresh start, something new.  I wanted to move to WordPress anyhow, and now my hand has been forced.  It’s a good thing!

So, in its new incarnation, what will you find here?  Well I plan on taking some time to write about the things that I think deeply about.  These things include software engineering best practices, software development methodologies, large scale software systems, intellectual property law and licensing, food, beverages, and sometimes just general navel gazing.  I can’t promise that I won’t get muddled in these thoughts or that I won’t deviate from the above formulae, but I can count on “the world” to call me out when I do.

In any case, more to come as I wrap my head around Word Press and its features (very impressed so far).

Cheers!