IT Shopkeeping

Who are those other people running around your office with numbers on their backs? What base do they play?  Which way should you turn to throw to them?  Who’s on first?  Knowing your own job is fine, but it won’t make you an MVP.  An all-star knows what everyone around them is doing and how to make plays on a team.

[tab:Stakeholder]
PLAYER: Stakeholder or Business Owner

The team wouldn’t exist without the Business Owners and Stakeholders.  This is the group responsible for the financial and business direction of the entire team.  If you’re a techie, you may not ever understand or even meet these people, and they will definitely never understand you.  But you need each other.  Business Owners and Stakeholders, I encourage you to have some gratitude for these players that slave away on your team to meet your quarterly goals and bring your technology into the future.  Everyone else, have you ever tried to run a business?  If you have, you know it’s not so easy and have some appreciation for the challenges.  If you haven’t, you may find it easy to poke fun at those in charge.  Pointy-haired bosses and such.  The real story is that these people undergo a considerable amount of suffering so you can receive a steady paycheck.  If you doubt their challenges, try having kids or just plan a trip to the movies with five of your friends.  Organizing people to accomplish anything is one of the most challenging feats anyone may aspire to.  It’s the Business Owners and the Stakeholders responsibility to choose worthwhile projects with clear direction.  It’s their job to know their own technical and business limitations and turn to experts for guidance when necessary so they are providing everyone with a clear, wise path to follow.  For the duration of the project, these people own the team.

[tab:Project Manager]
PLAYER: Project Manager

The right hand of the Stakeholders are the project managers.  Someone is tasked with the exciting job of remembering how much money and time is left and these are the lucky ones to do it.  Do they always care if the right technical choices are made?  No.  Do they relish elegant software architecture? Probably not.  Will they get crows feet when deadlines slip or money is flying out the door with no end in sight?  If they’re doing their job they will and if they don’t they’ll be fired.  Project managers are the white knights of the business interests and in a culture as anti-establishment and untrusting of corporate motives as software development it’s a dirty, unglamorous job.  Good software project managers are subservient to both their masters, the Stakeholders, and to the teams that work for them, putting in the extra time and effort to remove obstacles and smooth over frayed nerves.  As mean and uninformed as you think your project manager might be, their boss is inevitably meaner and even more uninformed.   Try and keep the project on schedule as best you can just out of pity for these poor people.

PLAYS

Project managers are often juggling the ball.  They are responsible for forces fundamentally at odds and in flux: people and their output.  This is where business needs and restrictions of budget, staffing, and resources meet individual human personalities and the project manager must attempt to comprehend and communicate the outcome with enthusiasm and honesty.  Their plays involve communications between individuals and within and between groups.  This requires powers of observation, analysis, and in an industry where most apparent life-threatening emergencies are resolved within hours, perfecting the measured response.  Fine points of scheduling are important, how employee vacations and personal schedules impact the team’s efforts.  Remaining in tune with upper management’s expectations will help the gameplay considerably.  Project managers must master the subtleties of politics and negotiation in order to obtain the resources needed to complete an endeavor without wearing out their welcome with those providing the goods.   Authority is a fickle beast and can be gained or lost quickly.  Project managers who have learned to cultivate empathy balanced with a firm sense of principles and priority will fare better than one who responds minute-to-minute to whatever appears to be the hottest fire or the most visible podium from which to be admired by all.

[tab:Analyst]
PLAYER: Analyst and Information Architect

These are the protocol droids of the software world – the translators – from BusinessSpeak to TechSpeak.  Dedicated hours of meetings with the Users result in pages of business requirements and workflow which these folks distill into Specifications.  Analysts are also the record-keepers.    The Specifications they produce are contracts with the Users for mutually defining the end product and setting expectations for project deliverables.  “Specs” also serve as directions to the developers and testers as to how the apps should look and behave.

Information Architect is a specialized Analyst who majors in the layout of data and controls on forms and web pages.  They’re multi-talented ninjas wielding design prowess, web knowledge, and application usability.   They produce detailed page mockups or “wireframes”, screenshots of how the application will look when it is completed.

If you’re fortunate enough to have analysts and an information architect on your team, count yourself lucky.  Most project and organizations aren’t well-funded enough to have such dedicated positions and the developers are saddled with the responsibility even though this isn’t a technical job per se and most developers hate writing anything down.

PLAYS

Analysts master the art of translation, comprehending the needs of the users and converting them into useable application designs.   Record-keeping is a crucial element on every project, having a clear recollection of each decision made regarding business requirements and their implementation.   The product memory for the entire team, analysts develop writing skills, document management expertise, and speak in a wide range of tongues so they may communicate across their organization from the most focused(read: thick-headed) user to the most talented(read: autistic) developer.  Above all, analysts are practical, mastering the art of pragma.  They decide where dreams become reality and where they must remain where they came from, in the clouds.  This requires a keen understanding of the project’s mission and how it is meant to implement the overall product strategy.  A senior analyst sees a project as just one step in the life span of a product, with dreams for future products, and a rooted sense of history for the product’s water under the bridge.  This sense of present and past tie into the analysts role and plays involving in record-keeping and product memory.

Analysts who completely master their plays position themselves to be a product manager.  They then move into the larger arena of product competition and life cycle, pitting their products against the product lines of the competitors.  This requires a studied understanding of their industry at large, the trends, pitfalls, and opportunities.

[tab:Developer]
PLAYER: Developer

How far have we come, O Brothers and Sisters?  From the social disgrace and obscurity of the nineteen sixties, seventies, and eighties, into the limelight of the twentieth-first century!  The Internet Boom made us bankable and Keanu Reaves made us sexy.  Software developers are the sherpas and the plumbers of the Information Age.  We create the ideas, the machines, and the infrastructure upon which Big Business now rests.

But we can’t let it get to our heads.  We are here to serve.  The economy of our company, our industry, our state, and our country depend on us to efficiently and affordably provide a lasting infrastructure for information management and dissemination.  The world depends on us to provide a stable foundation for life in the present and growth in the future.  No kidding and no pressure.

Software developers are the worker bees of the hive of the IT Shop.  We take direction from the Owners, Stakeholders, Project Managers, Analysts, Testers, and our Tech Lead.  Most developers report to no less than three people and often to many, many more.  In an ideal world, we program against documented Specifications using up-to-date software tools in carefully configured and well-maintained development environments, delivering clearly defined releases to patient managers, users, testers, and stakeholders under realistic deadlines on well-crafted schedules.  ROTFL?  Right.  That never happens.  Unless you can get everyone in your department to read this blog and get their game on…

PLAYS

The technorati, architects and developers, will hone their skills in object-oriented programming, design patterns, system modeling, and stay abreast of the multitude of daily-changing technical techniques.(I’m not going into those here because they would be out of date before I could place the period at the end of this sentence…    “.” )  Having a long-term game plan is a large part of successful development, and the business value is realized here where the money meets the code.  Is there a five or ten year technology strategy, or are applications written on an as-needed basis?  Is there an architectural foundation or are modules coded independently of one another?  Do new developers have any way of learning the ropes other than waiting for senior developers to catch their mistakes?  Certain plays aren’t obvious.  Communication skills are actually quite important in technical circles, particularly the translation of business-speak into technical dialects.  Some developers leave this to the analysts and managers but top-notch techies dive into the businesses they serve with gusto, learning industry-specific lingo and walking a mile in the moccasins of their users.  This approach, developers and architects expanding their circle of concern to include other team members, roles, and departments, reflects deeply into the code, and results in apps that work the right way.  By and large, developers hate meetings so code reviews, architecture meetings, and design reviews are generally few and far between.  There are, however, many ways to unify the team and tighten up their game.

The efficiency of a software shop can often be measured by the organization of the development environment.  A shop with more than one or two developers has complexities and challenges of code releases and shared libraries.  Additional developers and projects compound this problem.  The solutions involve a range of plays, from separation of the development environment from the testing and support environments, to source code control, to technical documentation.  Advanced shops carefully coordinate their flow of code, executables, documentation, and data through the pipeline from development into testing to demonstrations then live installation.  This requires the right tools, processes, and the appropriate technical talent, and most of all, a vision.

[tab:Architect]
PLAYER: Architect

Technical leadership directs the team of developers over the choppy seas of coding.  Many of the important decisions in a software project involve technical choices.  Which technology should we go with?  Should we use off-the-shelf components or roll our own?  Can we ignore these little bugs or will they cause serious problems soon?  It falls to technical leadership, usually a senior developer, to make these calls, or at least to organize a vote.   The “Tech Lead” works closely with the Project Manager to see that technical solutions and ramifications will affect the schedule and budget positively instead of negatively, to mitigate risk, and to rally the team to put out the inevitable fires.  Dedicated Tech Leads spend their evenings scouring the internet, blogs, and forums to catch up on the latest tools and technologies.  They eat code for breakfast and enjoy sharing what they know with more junior members of the team.

The Architect is a specialized breed of technical leader who is brought onto a project to orchestrate the planning of development methodology, tools, and process.  In addition to creating the sandboxes and workshops for the developers and designers to use and code with, this person is responsible for all issues which sound like “When we turn this thing on, will it work the way we expect?” And as importantly, “After some time passes, will it still work the way we expect?”  This includes considerations of performance, scalability, security, usability, maintainability and any number of other topics that may seem like abstract or academic discussions until the web server crashes and is down for three weeks.  An Architect can affect the roles and lives of many techies and businesspeople around them.  They should be excellent communicators and even better politicians.

PLAYS

The code produced by an IT shop reflects the essence of the shop.   Here is where knowledge, dedication, and workmanship can be transformed into effective, usable, successful business applications.  This is also where neglect, sloppy work, and ignorance can slowly bring a company to it’s knees.  Even the best programmer is going to have bad days.  This is why coding best practices and design patterns are important.  Here, too, is where architecture comes into play.   Coding minute-to-minute and project-to-project leaves the code base a sprawling, weedy, unmanageable bramble.  A shop which sets long-term goals for code growth will, in time, enjoy a pleasant, fruitful garden.   Where would you rather picnic?

[tab:Tester]
PLAYER: Tester or Quality Assurance Professional

Software has become such an indispensible aspect of our lives that an entire range of professions exist to ensure its integrity, fitness, and quality.  Quality Assurance professionals and Testers wait and watch for the next release of the application, with baited breath, then descend upon their prey like pack animals.  Mercilessly concentrating on and exploiting the apps weaknesses, they seek only to bring the software to its knees.  Poorly developed victims will go down quickly and result in “Critical Error” and “Blocking Error” reports, whereby the bloodied body is dragged back to the shamed developer to resurrect and repair the application.  Robust, well-wrought modules run the gauntlet easily, proceeding through the batteries of tests relatively unscathed.   In this way, the QA team and testers run an application through its paces, using the Specifications and Business Requirements as a guide.  It falls to them to prove or disprove that an app meets the User’s needs as agreed upon.

Note that QA is the final step in most software development schedules.  This means that after analysis delays, development mishaps, and release foibles, the QA team usually receives the application about two hours before it is due to the Stakeholders.  It’s a wonder these people stay at their jobs for longer than a month and without them the world would be filled with software that simply did not work.  Respect the QA team.

PLAYS

Few areas where plays and technique matter more than in testing.  The coordination between testers and developers is necessary for accurate test results.  Unlike development, where sloppy coding may do the trick at the time then can be fixed later, sloppy testing wastes time and resources that can never be reclaimed.  Poorly planned and executed testing can also lead directly to a poor user experience, which results in lost business.  A QA team with a tight playbook differentiates between the many types of tests: Smoke Tests, Regression Tests, Pre-Release Tests, Integration Tests, and User Acceptance Tests, to name just a few.  Each stage of development requires some measure of testing and solid communication and agreed-upon processes between testers, developers, support staff and users.

[tab:Sysadmin]
PLAYER: System Administrator, Configuration Manager, Release Engineer

Machines and software tools litter the floor of a software shop.  With cloud computing and virtualization, soon the entire Internet will be stuffed full of them like an old basement.  Someone has to keep them all running.  This falls to the MIS team, made up of Sys Admins or Configuration Managers.  From the requisitioning of new servers to the installation and configuration of the software on them, this group provides the physical and virtual foundation for a development shop to run.  Source Code Control sometimes falls in this purvey as well, that is the maintenance of the shop’s code library and release workflow.  This is the responsibility of the Configuration Manager and Release Engineer.

[tab:DBA]
PLAYER: Database Administrator (DBA)

Databases are complex and delicate shrubberies in the garden of Softwareball.  They must be tended, fertilized, and trimmed by expert hands or they become unsightly, unwieldy, and unusable.  The database administrator specializes in proprietary database tools and any number of languages including SQL and scripting.  A good DBA is a master of detail and a lover of repetition and responsibility.  Their plays include habitual backups, and a plan B, C, and D in general.  In Softwareball, data is money.  Superb DBAs have a nuanced understanding of the needs of the businesspeople and techies around them and can prioritize with brutal finality.  It’s never a bad idea to gift a DBA their favorite baked goods BEFORE you need something from them.