The Executive Singularity Project Management Methodology

Posted April 24, 2014 by developnorth
Categories: Morale, Project Management

Previously, I postulated that my employer had created a new project methodology called the Reality Free Project Management Methodology.  I think I’ve discovered the real project management methodology in use in my company: The Executive Singularity Project Management Methodology (ESPMM).

What is ESPMM and how does it work?

The Executive Singularity Project Management Methodology, at its core, is modeled on the gravitational singularity, or simple terms, the center of a black hole.  Armed with a semester of Quantum Physics (yes, I took quantum physics in college, but only because it was required) and a hastily read article on Wikipedia, I’ll explain how this works…

A Digression

A black hole is caused when a really massive star collapses on itself at the end of its life.  The gravitational force of this mass continues to pull in more mass, increasing the gravitational force.  At some point, the mass reaches a point where a gravitational singularity is formed.  The gravitational singularity is a point that has no volume, but contains the mass of the black hole, thereby having an infinite density.  Black holes also have an event horizon which is the last point before an object is pulled into the black hole.  Eventually, the gravitational pull is so strong that anything that passes the event horizon, even light, cannot escape.  As you approach the event horizon, time seems to slow down for anyone looking at you from quite a distance away, but to you, time continues as normal.  It has been theorized that it might be possible to exit a black hole into a different space-time.

What Does This Have to Do With Project Management?

Management kicks off a project.  They start to apply more and more pressure to the project.  As they do so, more and more requirements are added to the project, resulting in increased pressure.

Looking at the black hole model, one could say that the project requirements might represent the mass of the project, the resources allocated to the project would be the volume of the project, and executive pressure would represent the gravitational forces.

At some point, the executive pressure and the ever increasing number of requirements create what I term an executive singularity.  The executive singularity is a project that has no resources, but all of the requirements, thus achieving an infinite density.  The executive singularity would also have an event horizon which would be the point before something is pulled into the project and can never leave.

Practical Benefits of the Executive Singularity Methodology

From a management point of view, the Executive Singularity Methodology allows an ever increasing amount of requirements to be added to a project.  Once the singularity is created, management could only see anything up to the Event Horizon.  As a result, time would seem to slow down from anyone approaching the singularity which means that they should have plenty of time to deliver all of the requirements.  In fact, to management, far away from the executive singularity, time might appear to stop altogether for anyone trapped in the singularity, thus assuring 100% percent delivery of all requirements.

The Drawbacks to the Executive Singularity Methodology

The drawbacks to this methodology are only apparent to those who have been drawn past the event horizon and cannot escape.  For these unfortunates, time continues to function normally so there really is only twenty four hours in a day and seven days a week.  As a result, they realize that it’s impossible to meet the requirements of the project, but since they’ve passed the event horizon, there’s no way to communicate this to management.  In addition, the executive forces begin to twist and distort the participants.  It is theorized that it may be possible to pass through an executive singularity and come out in a different assignment, but to date, no proof has been found that this is in fact possible.  empirical evidence tends to show anyone trapped in an executive singularity is crushed by the weight of the requirements.   While this is certainly detrimental to the person crushed within the singularity, this is another benefit to management because it means less employees to pay.

Conclusion

I think I may have something with this theory and may look to publish a paper on it; perhaps it might win a No-Bull prize!  I’ll continue to collect empirical data and perhaps I might be able to pass through the singularity relatively unscathed.

I believe this accounts for the real reason why all of our projects at work really suck and no one else can see why.

Advertisements

A New Project Methodology!

Posted August 9, 2013 by developnorth
Categories: Uncategorized

I’m no Project Management Professional (PMP), but I have learned a fair amount about project management in my career.  I’ve actually had a few training classes in general project management as well as a specific project methodology.  I’ve also learned the differences between waterfall, lean, and agile.  But in my new job, I believed that I have discovered a brand new project methodology at my place of employment and I can’t wait to share it with everyone.

For my non-technical friends, project management is taking a large task (like developing a new system, or it could be building a house), breaking it into the stages, breaking the stages into tasks, figuring out the resources that are available, figuring how long it takes each resource to complete  a specific task, and putting that all together to tell you how long it will take to do the big task.  You have three variables that you can use to change the project: Quality (this would be a combination of the quality of work to be done and even the scope of the work), Resources (people and money), or Time.  A common adage in project management is that for any given project, you can only favorable control two of the variables at once.  For instance, if you want something done well in a very short time frame, you have to throw lots of resources at it (people and/or money).  If you want it cheap, but good quality, it will take a long time.  

But I’m proud to say that my place of employment (that shall remain nameless) has a groundbreaking approach to this dilemma.  Allow me to present the Reality Free Project Management Methodology (RFPMM). Let me explain how this works:

1) Take a major task that would be considered a project

2) Pick a manager who will manage the project

3) The manager picks the completion date

4) The manager assign resources – as a rule, no more than two people should work on this, even though others might be available.

5) Expect it to be done by target date.

The advantages to this are many – you don’t have to worry about pesky things like figuring out what tasks make up this project, how long it takes to do the task, whether you have enough resources, communicating plans and task schedules to the people doing the work  You just pick the date you want it done and the resources have to get it done by that time.

In all seriousness, this is how major (and even not quite so major) tasks are planned at my company.  Yesterday, my supervisor asked me to come up with a plan to convert a system built in one language to another…in two months.  By myself.  And probably while I also have to contribute to another important (but not as big task) as well as two major projects. On a monthly basis, tasks are assigned to developers for the fixed date release and there better have been an apocalypse to excuse not having your tasks completed for the release (even if assigned to you two days before release day).  

But there’s the beauty of RFPMM – it doesn’t matter.  You have a task and a due date. You can control all three project management variables because…reality doesn’t apply.

Hmmm…I wonder if I could patent this and then charge my company for violating my business process patent….

Say What You Mean, Damn It!

Posted September 15, 2011 by developnorth
Categories: Uncategorized

“You keep saying that word. I do not think it means what you think it means.” – Inigo Montoya, The Princess Bride

I guess I’m slowly becoming a grumpy old man, but one thing that really bothers me is when words are used to denote a meaning that really doesn’t mean what the person has intends it to mean.

Case in point:  The other day, I got a message about a list of web classes  at my day job.  One of them caught my eye: “The Attitude of Servitude”.  Huh?  Did they really mean that?  Are they really trying to get us to think like indentured servants?  Thinking that maybe my grasp of English vocabulary wasn’t what it used to be, I looked up servitude:
  • a condition in which one lacks liberty especially to determine one’s course of action or way of life
  • a right by which something (as a piece of land) owned by one person is subject to a specified use or enjoyment by another
Merriam Webster Online Dictionary

Who’s ready to sign up for this class?  Sorry, not me!

Suspecting that this wasn’t really what they wanted to teach, I did a Google search and I think I found the course description:

“… provides insights into building customer relationships through service. Customer service insights include: Seeking personal excellence; Intense customer focus; and Win-win spirit. This course will help you differentiate your organization from your competitors by following the outlined concepts.”

I suspect that the person who created this course was trying to be clever. Change the word service to rhyme with attitude and it sounds great… The Attitude of Servitude…except for people with  a vocabulary.  I’m sorry, I really don’t want to have the attitude that I have no liberty to determine my own course in life.  What’s the follow-on class…Smile and Be Servile?

In the corporate world, it happens constantly.  It makes me just grit my teeth and mutter under my breath. People constantly make up words out of existing words to try to make themselves sound smarter.  It’s like in high school when you have to write a 500 word essay and you made up variations of the same sentence so you could make the word quota.

But if I hear any sentences like “We need to incentivize people to be proactive in synergizing their learnings to create a new paradigm”, I think I might scream. How about just saying “We need to find a way to get people to come up with new ideas”?

The point of language is to convey thoughts and ideas to another person.  You know, communicate! When people start trying to make their language sound more intelligent by making up words or torturing existing meanings, they are not acting intelligently. They are not communicating; they are just attempting to show off.  I suppose nothing can be done about this because corporate speak and its ilk will be there so that someone can spend five minutes talking and not really communicate anything.  It’s a good PR strategy – talk for a while without really saying anything definite.

But my mission and my new mantra is “Keeping Things Simple”.  That doesn’t mean using simple words all of the time.  There something to be said about using one bigger word in the place of numerous smaller words.  But the point of communication needs to be about conveying the idea, not seeing how many words you can use.  We’re not in high school anymore – we aren’t graded on word count! (although at this point I’m at roughly 590.)

Michael’s Laws of Software Development

Posted February 11, 2011 by developnorth
Categories: Miscellaneous, Software Development

In the course of my career, I’ve come up with a few rules/laws that I’ve found to be true time and time again. Sadly, these laws are based on actual experience. So I thought I’d share them with the Software Development community (or the five people who read this blog):

I. Michael’s Immutable Law of Software Requirements

Users always perform the same process to the same data every time…except when they don’t.

II. Michael’s Law of Vocabulary Variance

Words like “required” seem to have a different meaning to a developer (“always must exist”) than to a user (“it must exist, unless I don’t feel like it”). Also “optional” also seems to mean “required”; unless, of course, if it doesn’t.

III. Michael’s Law of Feature Longevity

The feature that is a “must have” and is the hardest to code will be the feature that will be reversed in six months. See Laws I and II.

IV. Michael’s Law of Prioritization

Every feature or request is absolutely the highest priority, even if the requests are from the same person and there’s only one programmer to implement them.  When pressed to prioritize which features/requests should be addressed first, the answer is “all of them”.   Apparently, having dual core processors on computers now means that a programmer can program multiple features simultaneously.

V. Michael’s Law of Project Accountability

The lateness in delivery of code for testing is directly proportional to the perceived failure of the project.  However, the length of time it languishes waiting for testing and signoff, even if greater than the lateness of code delivery, has no effect on the perceived failure of the project. In a word, it’s always the developer’s fault.

VI. Michael’s Law of Diminishing Returns

When joining a successful company or new group within a company, that company or group will immediately lose resources (budget, personnel, etc.) approximately one year after you join it.  And it only gets better from there!

I’ll continue to update these as I uncover more laws of software development.  This blog would not be possible without the pioneering work of Mr. Murphy and all who came after him.

In Praise of Maintenance Programmers…

Posted July 2, 2010 by developnorth
Categories: Career, Software Development

I know this is supposed to be a blog about development, but I want to spend a few moments in praise of a group of technologists often overlooked in the discussions of software development: maintenance programmers.  There has been much discussion about “rock star” developers, particularly from Joel Spolsky at Joel on Software.  And that’s great.  Any discussion that raises the social standing of programmers is a good thing!  But I want to talk about the unsung heroes of software development and IT – the maintenance programmers.

First, a confession.  This topic is slightly self serving, in that in my new day job, I am now a programmer in the maintenance group.  In fact, my recent trials and tribulations at work made me really appreciate how hard maintenance programming really is and how the skills essential to maintenance programmers are a little different than a developer.

The Obligatory Star Trek Reference

Using Star Trek as an example, I see developers as the Starfleet Engineers who build the starship and the maintenance programmers as the Scotty’s of the world.  Think about it – Scotty is always enlisted to perform miracles to make the ship work because Kirk (the user) wants it to do something it was never designed to do or has messed it up so badly that it needs heavy duty maintenance.  And Scotty usually has to perform these feats of miraculous engineering under extreme time constraints or without key personnel or resources.  Sounds like the kind of day I had every day for the last week and a half!

Obviously, Star Trek is fictional because Scotty always gets the accolades and praise…when was the last time maintenance programmers got praised for working diligently to fix a problem?  Usually it’s, “That’s nice, now here is my list of another 20 things for you to fix…”

Skills Essential for a Maintenance Programmer

  • Ability to Read and Decipher Someone Else’s Code – It goes without saying, that most of the time, maintenance programmers don’t actually write the code they have to support.  Nothing says you’re going to have a day of fun like digging into a steaming pile of…code.
  • Ability to Be a Forensic Scientist – Not only do you have to be able to read the code, you have to figure out how it actually works in the REAL WORLD.  Developers rarely see their code live in the world and don’t have to worry about pesky details like when the database table is locked because one process is doing something while another is trying to update the same table.  You have to make friends with every kind of debugger/trace tool that you can lay your hands on so that you can do a little CSI work on the culprit (the problem).
  • Ability to be Sherlock Holmes –  Hand in hand with the CSI work, you need to be able to logically deduce what is happening from the (hopefully) piles of evidence you have discovered.  Remembering that when you you have eliminated the impossible, whatever remains, however improbable, must be the solution,  goes a long way in maintenance programming.
  • Dogged Persistence – You have to keep beating your head against the problem until either you win or the problem miraculously disappears.  This is where the rubber meets the road…you’re the one who has to get it working for the users.
  • Being a Jack of All Trades -While it’s great to be an expert in a development language, once that code hits the real world, it is likely interacting with any number of other things out of your control (like it might have been in development) – like web services, networks, databases…you name it.  Knowing at least something about all of the elements of helps give you an appreciation for all of the possible areas to explore.
  • Intuition – Sometimes intuition is the best tool for trying to figure out what is happening.  This is sort of an addendum to the previous skill.  When you’re grounded in a varied background, you begin to make connections and improve your  intuitive skills.
  • Patience – You really need to have the patience of a saint to keep from going crazy.  Each roadblock that’s thrown up by the code or the production environment has to be either worked around or driven over.

The Stigma of Maintenance Programming

But let’s face it, maintenance programmers don’t get treated the same as developers.  Why?

  • They are not perceived as being able to grasp new technology – Maintenance programmers may seem like they don’t “get” new technology, but I don’t think that’s universally the case.  In my limited stint as a maintenance programmer, I have to understand a wide variety of things – XML, web services, C#, Java, JavaScript, SQL Server, and mainframe JCL to support the applications.  Sure there’s old technology, but there’s a good chunk of new technology that I have to learn quickly.  And usually without the training that the developers got so they could figure out how to develop the system.
  • Keeping things going is not as glamorous as building new stuff – This is universal it seems.  This happened at a previous employer. I’ve had co-workers and friends that never seemed to do well and weren’t looked on favorably by management because they went about the job of keeping things going silently and efficiently.  I know that some of peoples were on the list of people to be downsized because they weren’t producing new exciting work.  But they kept the business going.  If it were my business, I would have hired them without reservation because they were model workers.  Yet somehow, the idea of doing what’s needed to keep the business going is not as important as producing new things.  I don’t care how many new systems/products you develop, if you can’t execute on a day to day basis, it just doesn’t matter.
  • They are not “real” programmers because they don’t create anything – That’s simply hogwash.  Maintenance programmers are usually the ones who have to extend/recreate/totally rewrite the original application when the business needs (or the user’s minds) change.  They are the ones usually stuck with refactoring – now that’s a REAL programming task.

What Can Be Done to Fix the Maintenance Programmer’s Lot?

In reality, probably nothing.  As a business culture, we only seem to care about the next new thing.  I realize that business can’t just stay focused on doing the same thing all the time, but if you don’t have stable, dependable systems, all the new development work in the world is not going to keep the business going.  So, here’s my wish list for what could be done to help maintenance programmers:

  • Recognition for the important work that’s done – Sure, there might be some sort of celebration for a new project that was completed, but how about some sort of recognition for someone who finally fixed a long standing problem?  Came in in the middle of the night to get the jobs running?  Yes, I know it’s part of the job, but you know what?  So is delivering a project if you’re on the development team.  A little recognition would could go a long way.  It doesn’t have to be an elaborate thing: an email to the group praising someone’s efforts or a mention at a staff meeting. Although food is always good!
  • Rotate developers and maintenance programmers through projects – I think it would be great if one maintenance programmer could join a specific development project, while one development programmer took a tour of duty as a maintenance programmer.  I think it would have very many positives – maintenance folk get in on the ground floor and get to build something , they get to see the struggles that developers have in trying to create something from nothing, and they may get a chance to pick up a new technology.  Developers get to see what it’s like to have to support code over the long haul and deal with the inevitable changes that occur as the software is let out in the wild.  This may help inform their development choices later…especially if they know they may have to support it at some time.
  • Make sure that maintenance folk get the same training opportunities as developers – How many times have you seen this?  A new technology comes in and the people who are going to implement it get training.  Down the road, they move on or the system moves to the maintenance group…who now have to figure out how to support or even change this thing.  But there’s no training for the maintenance group because the company has already spent enough money training people…who are now completely consumed doing something else and have no time to help.  If it’s important in enough to train people to develop with a technology, it’s just as important to train the maintenance people!

So to all my fellow maintenance programmers out there:  keep the faith and keep doing what you’re doing to keep things running!

I Once Was Lost, But Now I’m Found…

Posted April 17, 2010 by developnorth
Categories: Uncategorized

After a long silence, I’m back…in more ways than one.  I’m happy to report I’ve been gainfully employed for almost three  months now.  And I’m back to programming on my own project…and writing a blog.

Why the silence?  You would think that while I was unemployed, I’d have a lot of time to write.  And that’s true.  But as the title of this blog implies, I was lost.  I couldn’t focus on anything.

Anatomy of My Unemployment

After the initial depression and rage of being involuntarily separated, I settled into a somewhat productive rhythm where I looked for jobs, did some programming on my project, and took care of my son over the summer and doing a lot of cooking.  And all was well…OK, all was at least not totally sucky.

Soon the summer faded into autumn and I still was no closer to employment than I was the day I was let go.   By September I had only had one interview.  But not many rejections…because a rejection letter would imply that you would actually receive a response.  And a job that I had previously applied for re-opened at a local company and I re-applied.

And…nothing.  I did get a second interview and was promised a response within a week….And nothing….three weeks of calls and email to company netted….an email that they wouldn’t be extending an offer.  I had other interviews and never heard another word from all but one of the companies. 

Autumn became winter and again, I had no more prospects than on the day I was escorted out.  And the winter weather drove me inside and one of my only outlets, running, was shut off.  And more emails and calls…and no response. 

And Then a Ray of Hope

Then an interview….and then a programming assessment test (that told me I wasn’t a great programmer), then a second interview and almost 7 months from the day I was involuntarily separated, I started a new job.

The Emotional Toll of Unemployment on My Psyche

Months of being ignored made me feel more and more worthless.  Each unreturned call or email was another chip out of  my confidence.   I could make no plans and had no plans.  I had no schedule other than getting my son up for school and being here when he finished.

And as a result, I couldn’t focus.  I’d sit in front of the computer to program or write…and…nothing.  I’d mess around on Facebook or play games or go play on the Wii.

 What I Learned from This Ordeal

  • I (apparently) am a more structured person than I thought I was  – I’ve always thought I was more of a random person, but apparently I need structure.  I had no schedule or anything to frame my day. And I got nothing done.  Since returning to the nicely structured world of 9:00 – 5:00, I am able to get more accomplished in less time because I think I know I only have x minutes to do something, so I focus and do it.
  • “I’m good enough, smart enough, and doggone it, people like me” – I guess I needed Stuart Smalley with me during the dark days of my unemployment.  In my new job, I’ve been able to jump in and be really useful – in fact, coming up with a solution for a problem that the vendor hadn’t figured out yet. Self confidence certainly takes a beating when you’re unemployed and it’s hard to remember that you are as good as you think you are.  See this excellent article by Pamela Slim.
  • Working as part of a team sure beats the lone wolf approach – In my new position, I’m part of a group supporting a couple of systems and we are part of a bigger team supporting a whole line of systems.  And I like it!  Although we’re dealing with the challenge of coordinating changes and activities, it’s a refreshing change from having to do everything yourself!  For most of my career, I’ve been the only person working on a project or, in the case of my previous employer, the only IT person responsible for all of the systems.  Having a much smaller, focused scope of work is…refreshing.

Mike Has Found His Groove

I feel like I’m finally getting back in the groove.  I realized that despite being ignored, rejected, and told that I’m not a good programmer, I AM a decent programmer.  Maybe I’ll never build truly amazing, transformational software, but I’m a decent developer.  I have the desire and stubbornness to not give up on problems.  I may be a bit of a jack of all trades, but it continues to serve me well. 

So, I’m back and I’m getting back to development and blogging. 

I am geek, hear me roar!!!

Running…and Software Development

Posted August 17, 2009 by developnorth
Categories: Miscellaneous, Software Development

This spring, I took up running.  To anyone who knows me, this comes as a huge surprise.   Up to this point in my life, I have always hated running.  I decided I wanted to get healthier and start losing weight, so I started using the Wii Fit we got at Christmas. I gradually worked my way up to being brave enough to do the running in place exercise.  And I sort of didn’t hate it.  I actually got good at it and was soon running a couple of virtual miles a day.

I thought, “Hey, I can start running outside”.  So I laced up the sneakers and ran to the end of my street ( about 0.6 miles)… and felt like I was going to die.  For the next three days, I felt like my thighs were going to explode everytime I moved.

A couple of weeks later, I tried again.  This time, I got a real running plan and followed it.  It started slowly with more walking than running.  Each week, and later each run, increased the amount of running and decreased the amount of walking.  After eight weeks, there I was running for 30 minutes straight for the first time in my life.

So What Does This Have to Do With Software Development?
I’m in the middle of rewriting an application and trying to upgrade my skills all at the same time.  And my result to date has been much like my first attempt at running.  I think I can do it because I’ve done it before and I start hammering away…and then it doesn’t work and my head starts hurting from not seeing what I should be doing.  I’m trying to run before I’ve built up the mental muscles that support the understanding that I need to move forward.   What I need to do is to start walking and adding my running minutes gradually. 

Who Cares?  Why Is This Important?
I think one of the weaknesses of technical people (myself included) is that we don’t like to admit we don’t know something.  We’re often thrown into circumstances where we have to do something we’ve never done before.  And so we boldy go where we’ve never gone before….and get frustrated.  We may reach  the solution, but we feel like there has got to be a better way.   Sometimes we get lucky in the Google roulette and find a code snippet that will do most of what we need without ever having to think about it.  Sometimes, this is a good thing – especially if it’s for one esoteric feature that a user ABSOLUTELY has to have, but it’s not  part of the core of the application (like say, a routine for changing the colors of the graph reports).  But it’s very easy (and tempting for the sake of expediency) to throw together a whole application of disparate snips of code…and that is a recipe for disaster.

What we should be encouraged to do at our places of work or even on our own, is to embrace the beginner’s mind.  By beginner’s mind, I mean that stage where you go through the basic exercises and start to make the connections that enable you to figure out how to more and bigger things.  In beginner’s mind, you don’t necessary even know what you don’t know.  But you start slow and build the intellectual muscles that you need to start.  And you continue to build those muscles so that you can do more.

How Do You Begin the Journey of a Thousand Miles?
 With a single step, Grasshopper.  By that I mean start at the very beginning.  For me, I’m going back to the .Net books that I have that patiently walk you through the steps to building a .Net application.  No more skimming to find the section that I think will do what I need to do. I also will look at Microsoft’s tutorials online and also squeeze in some online training.  As I learn, I will start to apply each piece to my application, re-enforcing my learning.  To speed up, I have to slow down; move carefully through the preliminaries until I have mastered them.

Because running is just like software development – just because you have been doing for a while, it’s still never really easy – it just gets less painful.