I've had the pleasure of meeting lots of developers from around the world in many different organizations that I've worked for - either as an employee or as a consultant. I'm still surprised when I meet individuals that think of this profession as some sort of magic. They are perplexed that men and women sit down and create all of this stuff that we now use as a part of our regular lives - apps on our smartphones, apps on our tablets, the programs we use on our laptops and desktops to the applications that we run on our thermostats in our homes. You seemingly can't go anywhere without running in to things that are run by software.
My first professional programming jobs used things like dBase III, Clipper and Basic - storing information in dBase III file formats. And yes, I've just dated myself! Anyhow, I then graduated on to Visual Basic, C, C++, C#, Java, JavaScript, Ruby, Ruby on Rails, a very brief stint with Assembler. Data was stored in Oracle, DB2, MySQL and SQL Server You get the idea, I've worked in a lot of languages and haven't even listed all the scripting tools I've used over the years. I've used these languages in all sorts of shops - sometimes it was on projects where I worked alone (oh, how I long for those days). Sometimes it was in large organizations, with sophisticated development processes, where teams were located across multiple locations and continents. Sometimes I got to sit next to the people who would end up using the code that I was writing. Sometimes I never met the people - I worked from written documents and interacted with the project manager and quality assurance team. Sometimes the code that I wrote was used by 1 or 2 individuals, sometimes it was used by people across the globe.
I love writing code, and even though it's not my role anymore, I still write code at night so that I can continue to learn and keep my skills somewhat fresh. I won't kid myself to think that I can get back down in to the trenches with some of the developers that do this all day long, day in and day out. However, creating software is still something that I like to do - I can really get in to the zone and not realize that hours have gone by, before I come up for air.
Now, along the way, I caused my fair share of Project Managers to loose sleep, go grey prematurely, and I'm sure I did a number on their blood pressure. In many ways, when I first started, I didn't understand my role in the whole project thing. Wasn't I just supposed to sit at the keyboard and make it happen! As sure as I'm sitting here writing this article, I'm positive that my old managers, and project managers that I worked with, would tell you that I wasn't too keen on following the rules. To be very blunt, I was aggressive in the way that I approached my job. I wanted to get things done - heck, talk to the people I work with today and they'll confirm that last statement. I'm still aggressive - the difference is that over the years I've learned to temper my natural tendencies and understand that sometimes rules and process do add value to the overall flow of the Project Lifecycle.
Wow, that was a long winded intro to the topic! And, if you haven't figured it out yet, I want to talk about the person generating the code and their role in the Project Lifecycle process.
Take a look at the titles at the top of this posting - I generally don't care what you call yourself, you're developing software and you do have some level of responsibility to your team. Even if you consider yourself a team of one, unless you are the only person that will ever use the software you are creating, the team is larger than yourself. At a minimum, it is two people, yourself and the one other person on the face of the planet that is using your app. Hopefully, the number of people using your app is a lot larger. Many times, working in an organization, you will be one of a larger team - other programmers, the project manager, quality assurance, end users, designers, etc.
If you are developing code that others are going to use, you have a responsibility to the other people that are on the team.
- Setting proper expectations as to when you will hit specific milestones.
- Holding yourself accountable to complete the identified work between milestones.
- Making sure that the quality of code being delivered to the test teams is adequate.
- Keeping everyone that needs to know in the know on any issues that come up that are preventing you from making progress.
- Helping to create mitigation plans when something goes off the tracks and is jeopardizing the milestones, the quality or the functionality of what is being delivered.
- Ensuring that you keep focused on assigned project activity.
You see, here's the rub, when you miss the milestones for work your responsible for, the project and future projects all get impacted. Somewhere, in the organization, plans have been made on specific things happening within a specific order. Project A gets completed and moved in to production. While Project A is moving it's way through the Project Lifecycle, typically Project B will get started so that when the developers are done with activity associated with Project A, new work is waiting for them. If the work your responsible for is acting like a logjam, then Project A isn't going to get in to production and Project B's work is going to get delayed. Now Sales and Marketing have a problem because they've promised customers that they'll be able to use the functionality by July 1st - whoops just kidding, can't get it to you now until September 30th. Oh, and that new project you wanted started, we can't touch that yet - don't even bother to ask us about the delivery date.
This is real stuff, sometimes contracts have been written around the delivery of specific functionality, or entire marketing campaigns are laying in wait ready to go. Sometimes those contracts have costs associated with them if the company you're working for can't deliver. Sometimes the marketing plans are time sensitive and if you're late delivering the code to production, they have to spend additional dollars replacing the pieces of the campaign that no longer make sense.
And just so you don't think it's the non-technical teams that are affected, what about your buddies down the hall in the quality assurance area? Any idea on what they are trying to juggle? No, it's not just your project. They have multiple projects coming through the pipeline hitting their test environment. When they have to keep retesting your package because the quality is horrid and you keep crashing their system. When they can't test because you can't deliver code in to their environment. What do you think happens to finely tuned dance of projects winding their way through the various environments in to QA? It all comes crashing down. What you're not noticing is the scramble happening behind the scenes to put all the pieces back together.
Did you do a design? Did you base your estimates off the design vs a hunch? Those are bad problems to have. Ok, there all bad, but those are really bad. Did you misjudge one of the requirements and underestimate the time needed to develop something? Did you encounter something in the test environment that caused your code to fail that wasn't within your control? Those aren't good, but at least there's an explanation. It's your responsibility to quickly inform the Project Manager of issues and whether you can get back on track, whether you need assistance in removing the road blocks, or if the problem really is of the type where there is going to be an unexpected delay.
I'm going to go back to a statement I've made before, we're human. Sometimes we make mistakes. Here's the million dollar question - did you make the mistake because you didn't want to follow basic rules when it comes to developing software. Yeah, those rules, the ones your company calls the Software Development Lifecycle. If you're not supporting the process, you're working against the team, your manager, the project manager, the department, the organization and ultimately your customer.
Tags: Project Management, SDLC, Project, Management, Conflict, Resolution, Project Manager, Software Development Lifecycle, Project Lifecycle, Project, Manager, Development
For more information on David L. Collison: LinkedIn Profile
No comments:
Post a Comment