Continuous improvement is something we should all endeavour to pursue on a daily basis irrelevant of our chosen field. For me I am not a natural geek. I never built my own computer and never wrote my own gaming engine. I am much more interested in business than computers. What I love about computers is the way they can stream line our processes and, ironically, how unforgiving they are. They do what they are told, not you you meant. To me this poses a nice daily challenge and keeps my brain from turning to mush at work. Because i am not a natural geek I have to actively push myself to learn things with regard to IT.
When PowerShell came out a few years ago I looked at it in fear. I have never really been a shell guy. My 'nix mates were always playing on the green screens and I secretly knew there was a lot of power there but it was too much of a mind shift from the comfort of my drag-n-drop/intellisense laced world... But I knew it was a weakness and jumped in feet first.
Although i am still a complete n00b at PowerShell I can get what i need done with it. I am comfortable with the tools and have got real return on my learning investment. I got uncomfortable and it paid off in spades. I have even moved on to PSake and replaced most of my build and deployments steps to be completely PowerShell/PSake based, a feat I am pretty proud of. It has also helped immensely in me picking up Rails and Git, both of which are command line driven.
For me the next thing I think I really have to tackle is UML. I have dodged it for years.
I draw diagrams a lot. I use a white board every day and like to draw while I talk. I feel in mixed audiences it help get points across by using multiple forms of communication at the same time, voice body language and diagrams. However I am communicating I should be adhering to common practices where possible (as my last post pushed), when there is a common language, you should use it.
For diagrams in nerd world its all about UML.
My dislike for UML stems from my dislike of concrete documentation. I have inherited too many projects that have had documentation that did not marry up to the implementation, with UML typically being one of the worst offenders. It is incredibly frustrating and most importantly wasteful; wasted time, money and trees (paper has to come from somewhere)!
So I sit thinking that perhaps I was throwing the baby out with the bath water; UML is not bad, inaccurate documentation is bad. If I am to communicate with diagrams then I should use the common language. I also understand there is a time to be pragmatic and a time to be dogmatic. Most of the time a couple of boxes with some lines joining them will suffice but the ability to step up to the more accurate implementation is a worthwhile ability.
So my UML journey begins... or at least is reborn.
Showing posts with label communication. Show all posts
Showing posts with label communication. Show all posts
Monday, April 26, 2010
Monday, April 12, 2010
What is Regression Testing?
We are on a journey. The company I work for is a very large one and has suffered some lag in migrating to modern ways of software development, a situation many companies of this size often find themselves in. Fortunately the team I work with have come together to make a conscious and consistent effort to improve our area of influence. First and foremost was the introduction of a structured developer oriented testing plan. Because we are a development team we started with unit testing, integration testing and some build scripts to run these tests. From there we have improved they way we do those tests, streamlined our scripts and made CI a solid part of our process. Automated deployments have become easier too leading to automated staged deployments. We are now at the stage where we are adding in Fitness and UI testing to the equation.
Each of these step have been driven from the ground up. We have had to, carefully, maneuver these processes into our daily process and show the benefits to management. It has taken time but they have responded very well; so well that they are jumping on board! This is a great thing and has made all the hard work, and it was hard work, worthwhile.
However there are still political games to play. The language is fractured and management want to throw around terms that they don't really understand and force their idea of these terms onto the very people that introduced them to the department, sound familiar? ;)
"Unit Testing" and "Regression Testing" are two of the terms du jour. Unit testing "means" something a developer does and regression testing is an automated UI test that a non techie can watch as it magically clicks away at the screen. This, as you may know, is not correct... well not strictly correct; and in a place where the language is so commonly fractured it is hard to justify fighting for seemingly such trivial victories.
So instead I vent here.
The things that i felt i needed to express most importantly are:
Any automated test is a regression test
- and -
You do not write regression tests.
What i am referring to in that last statement is merely the fact that you write a repeatable test that tests a certain unit, module or scenario, that can be automated and then your check it in to source control. The very notion that it is part of your build process/continuous integration means it now acts as a regression test.
So our tests that
Please don't make the mistake of thinking you will explicitly write a regression test. The test should test that the code produces a specific outcome e.g. enforces a business rule.
The automation and maintenance of a healthy CI environment makes those tests regression tests.
I guess the key here is really your CI process. If the tests can be dodged or accidentally not run somehow then this will need to be addressed.
Make the pit of success an easy one for you team to fall in to and let them know regression tests are a side effect of good daily habits.
Each of these step have been driven from the ground up. We have had to, carefully, maneuver these processes into our daily process and show the benefits to management. It has taken time but they have responded very well; so well that they are jumping on board! This is a great thing and has made all the hard work, and it was hard work, worthwhile.
However there are still political games to play. The language is fractured and management want to throw around terms that they don't really understand and force their idea of these terms onto the very people that introduced them to the department, sound familiar? ;)
"Unit Testing" and "Regression Testing" are two of the terms du jour. Unit testing "means" something a developer does and regression testing is an automated UI test that a non techie can watch as it magically clicks away at the screen. This, as you may know, is not correct... well not strictly correct; and in a place where the language is so commonly fractured it is hard to justify fighting for seemingly such trivial victories.
So instead I vent here.
The things that i felt i needed to express most importantly are:
Any automated test is a regression test
- and -
You do not write regression tests.
What i am referring to in that last statement is merely the fact that you write a repeatable test that tests a certain unit, module or scenario, that can be automated and then your check it in to source control. The very notion that it is part of your build process/continuous integration means it now acts as a regression test.
So our tests that
- Test a unit, i.e. an xUnit framework which may also uses mocks and stubs etc
- Testing seams or integration points i.e. DB tests, file systems tests, web service tests etc
- System smoke test
- High level acceptance tests using tools like cucumber, fitness etc
- UI testing - i.e. a button clicking framework like QTP
Please don't make the mistake of thinking you will explicitly write a regression test. The test should test that the code produces a specific outcome e.g. enforces a business rule.
The automation and maintenance of a healthy CI environment makes those tests regression tests.
I guess the key here is really your CI process. If the tests can be dodged or accidentally not run somehow then this will need to be addressed.
Make the pit of success an easy one for you team to fall in to and let them know regression tests are a side effect of good daily habits.
Tuesday, October 28, 2008
Technical Competence and the Interview Process
As I begin the job hunt all over again I am renewed with the realisation that sales skills, although possibly only rarely used in day to day coding, are as important as ever. Over the last 2 days I have been talking with friends, former colleagues, recruiters, HR and connections from all of the above in the Perth IT market regarding jobs.
The people who dont know me just want to to know what in vogue technical skils I have. Buzz wordy stuff that pass with the wind like WPF, MOSS, Asp.Net MVC etc etc
These technologies are all great at helping us do our job faster, prettier and more consistently but they only HELP. Core coding concepts, IMO, are of a much greater importance. I am not a WPF guru. Can i learn it? Bet your ass I can, in fact I am now. I give myself 6 weeks to do so and to be come good at it. Why six weeks? As I have been around the block a few time i have picked up a few technologies, API's & languages over the time. What i find is the more technologies, API's & languages I learn, the faster I can learn the next one. There is such a thing as "learning to learn".
In the past 2 years I feel I have become a much better developer in general.
Alot of that knowledge has come from reading the dozens of books and thousands of blog/forum posts, watching multitudes of videos and seminars and attending and presenting gigs like the Alt.Net open spaces... basically all the things that have stolen quality time from my friends and loved ones. Alot of that knowledge has come from using 3rd party API's that both kick ass (like StructureMap) and suck (like Infragistics). You learn from both, however it is with continuual exposure to new APIs that you are exposed to overall patterns and styles that you begin to associate as good or bad.
for example: Over the last couple of weeks I have found myself talking to a few friends and colleagues about the Law of Demeter. Infragistics is a perfect example of why this law (or guideline) exists. Having 5 properties chained off to change a setting in the grid is stupid and shows poor API design. Having not used this API i may not have "got" that specific law (lemons => lemonade). ;)
Learning languages like Python, Boo, F# and Ruby highlight the strengths and weaknesses of my own day to day language C#. It also highlights the fact the Java, VB.Net and C# (or whatever other c based managed language) are basically the same and people who argue between C# over VB.net or Java over VB.net need to learn a new language. Possibly they just mean they believe the .Net framework or libraries are better than java (or vica versa etc) and don't realise it.
Anyway...
Having been in the position of the interviewee and interviewer now I can see what I look for is basically the opposite of what recruiters look for... well to a degree. I assume by the time the candidate has got to me the recruiter has figured out the candidate has
-used .Net for a number of years
-has used the basic technology we are interested in (win, web, services, messaging etc)
What I look for is if the candidate has just done the one technology, eg just Asp.Net over WinForms for example. I mean they can not help that their employer dictates that what they used, but they can, in their own time, investigate other angles. In this instance i would also ask
-Have you used an MVC framework such as Monorail or ASP.net MVC?
-When did you use it and which version?
-what did you find different/better?
-Did you ever use it in production?
-have you used JSP, Ruby on Rails or Groovy on Grails or any other web based framework in another language?
-What CMS's have you used... etc etc
I don't care really what the answers here are, I am just fishing to see if this guy is a 9-5er or someone genuinely interested in his job. A 9-5er would take what the boss has given him and stick with it. Someone serious about their job investigates things outside of his comfort zone and finds out why this alternative exists and evaluates if it can help him perform better.
I also look for basic OO skills. If the candidate has never used Asp.Net but has ninja coding skills and is passionate and enthusiastic I would take him on. I can teach a monkey Asp.Net in 3 weeks. I cant teach enthusiasm. By that notion i also look for the knowledge of test and mock APIs and the use of framework libraries (e.g. castle and spring) as they tend to show the candidate understands the benefits and quality of code that can come with using such a tool.
Unfortunately this logic does not bode well with recruiters who want to pattern match. So the sales hat goes on to please the gate keepers. My problem is I wont lie to get a job. It has probably cost me some pretty kick ass roles/pay packets but, you still have to look yourself and co-workers in the eye everyday. The problem is the recruiters encourage it. My tack is to try and sell the global picture, its just not that easy. The same is true for interviews with non technicals such as PMs. They don't care if i know the intricacies of 5 different IoC containers, they want to know if I delivered production ready software on time, and so they should! However they still have the notion of patten matching. My lack of an ultra specific skill may have cost me a job yesterday (you will never guess what that skill is!). The problem is the guy would have given the job to someone of much lesser ability who had the the skill listed on his resume in a previous job. He has been hunting for months for this person... which to me would mean alarm bells ringing if I was him. If i fell in to that situation i would look for good people that you can train. If the good person has the skill set, awesome! If not, get the best you can and train them, FAST.
Fortunately I know people in the market and luckily I haven't burnt any bridges and have forged some pretty good relationships here in Perth. Which is lucky, because Perth is a small very well connected network. So hopefully mouths start moving and the word gets out that a new developer is in town ;). Otherwise I may follow a good friends advise and make it a leisurely summer of freelance development and lying on the beach, corona in hand.... things could be worse ;)
I would like to hear other comments from others... from the perspective of both the candidate and the employer.
cheers
Rhys
The people who dont know me just want to to know what in vogue technical skils I have. Buzz wordy stuff that pass with the wind like WPF, MOSS, Asp.Net MVC etc etc
These technologies are all great at helping us do our job faster, prettier and more consistently but they only HELP. Core coding concepts, IMO, are of a much greater importance. I am not a WPF guru. Can i learn it? Bet your ass I can, in fact I am now. I give myself 6 weeks to do so and to be come good at it. Why six weeks? As I have been around the block a few time i have picked up a few technologies, API's & languages over the time. What i find is the more technologies, API's & languages I learn, the faster I can learn the next one. There is such a thing as "learning to learn".
In the past 2 years I feel I have become a much better developer in general.
Alot of that knowledge has come from reading the dozens of books and thousands of blog/forum posts, watching multitudes of videos and seminars and attending and presenting gigs like the Alt.Net open spaces... basically all the things that have stolen quality time from my friends and loved ones. Alot of that knowledge has come from using 3rd party API's that both kick ass (like StructureMap) and suck (like Infragistics). You learn from both, however it is with continuual exposure to new APIs that you are exposed to overall patterns and styles that you begin to associate as good or bad.
for example: Over the last couple of weeks I have found myself talking to a few friends and colleagues about the Law of Demeter. Infragistics is a perfect example of why this law (or guideline) exists. Having 5 properties chained off to change a setting in the grid is stupid and shows poor API design. Having not used this API i may not have "got" that specific law (lemons => lemonade). ;)
Learning languages like Python, Boo, F# and Ruby highlight the strengths and weaknesses of my own day to day language C#. It also highlights the fact the Java, VB.Net and C# (or whatever other c based managed language) are basically the same and people who argue between C# over VB.net or Java over VB.net need to learn a new language. Possibly they just mean they believe the .Net framework or libraries are better than java (or vica versa etc) and don't realise it.
Anyway...
Having been in the position of the interviewee and interviewer now I can see what I look for is basically the opposite of what recruiters look for... well to a degree. I assume by the time the candidate has got to me the recruiter has figured out the candidate has
-used .Net for a number of years
-has used the basic technology we are interested in (win, web, services, messaging etc)
What I look for is if the candidate has just done the one technology, eg just Asp.Net over WinForms for example. I mean they can not help that their employer dictates that what they used, but they can, in their own time, investigate other angles. In this instance i would also ask
-Have you used an MVC framework such as Monorail or ASP.net MVC?
-When did you use it and which version?
-what did you find different/better?
-Did you ever use it in production?
-have you used JSP, Ruby on Rails or Groovy on Grails or any other web based framework in another language?
-What CMS's have you used... etc etc
I don't care really what the answers here are, I am just fishing to see if this guy is a 9-5er or someone genuinely interested in his job. A 9-5er would take what the boss has given him and stick with it. Someone serious about their job investigates things outside of his comfort zone and finds out why this alternative exists and evaluates if it can help him perform better.
I also look for basic OO skills. If the candidate has never used Asp.Net but has ninja coding skills and is passionate and enthusiastic I would take him on. I can teach a monkey Asp.Net in 3 weeks. I cant teach enthusiasm. By that notion i also look for the knowledge of test and mock APIs and the use of framework libraries (e.g. castle and spring) as they tend to show the candidate understands the benefits and quality of code that can come with using such a tool.
Unfortunately this logic does not bode well with recruiters who want to pattern match. So the sales hat goes on to please the gate keepers. My problem is I wont lie to get a job. It has probably cost me some pretty kick ass roles/pay packets but, you still have to look yourself and co-workers in the eye everyday. The problem is the recruiters encourage it. My tack is to try and sell the global picture, its just not that easy. The same is true for interviews with non technicals such as PMs. They don't care if i know the intricacies of 5 different IoC containers, they want to know if I delivered production ready software on time, and so they should! However they still have the notion of patten matching. My lack of an ultra specific skill may have cost me a job yesterday (you will never guess what that skill is!). The problem is the guy would have given the job to someone of much lesser ability who had the the skill listed on his resume in a previous job. He has been hunting for months for this person... which to me would mean alarm bells ringing if I was him. If i fell in to that situation i would look for good people that you can train. If the good person has the skill set, awesome! If not, get the best you can and train them, FAST.
Fortunately I know people in the market and luckily I haven't burnt any bridges and have forged some pretty good relationships here in Perth. Which is lucky, because Perth is a small very well connected network. So hopefully mouths start moving and the word gets out that a new developer is in town ;). Otherwise I may follow a good friends advise and make it a leisurely summer of freelance development and lying on the beach, corona in hand.... things could be worse ;)
I would like to hear other comments from others... from the perspective of both the candidate and the employer.
cheers
Rhys
Friday, April 11, 2008
Ignorance
My ignorance of stuff often astounds me. My complete lack* of understanding of data binding on the UI is hilarious. Our UI guy just schooled me on it and I am very impressed. Just another reason why I think coding in layers is best. We work in verticals so my ui stuff sucks compares to his.. please just leave me in the back end server side stuff. Obviously one could argue that working in verticals means we get exposed to these concepts, but i would rather that be done more formally in weekly code/nerd talks where the UI guy gets up and does a Data binding or Win UI Validation talk , in the same way i do TDD, or WCF or Nhibernate...
Tuesday, December 18, 2007
When is a bug not a bug?
I am sure the Tester at the place I currently work at secretly hates me. He is far too nice and far too professional to ever say... but i am sure of it.
He is in a position where he knows what the application we are building should do and how it should do it. Unfortunately this is only ever communicated to me after I have built the module. He doesnt write the use case so dosen't get a chance to prewarn me.
These changes are raised as bugs (as we only have the concept of bug, no concept of a change request) and so it looks like my code sucks as i have a couple of dozen bugs logged against my name (which is standard across the team). I dont like the idea of my code sucking. While looking through the buglist today, after reading the first 12 and realising that they were either A) Not bugs, but changes or B) not my bugs to fix; I got a little stroppy.
*begin blowing trumpet*
Now, when I get a use case I assume that this is what is required... I know, what an idiot... so I write my unit tests and do the whole Red, Green, Refactor like a good TDD agile boy,
*end blowing trumpet*
however I forget that we only call ourselves agile we are in fact... dreamers.
Huge numbers of tests fail and are left unattended, iteration after iteration... our scope is non existent.. our use case are guesses at what we kinda, maybe want and are completely ok to change at any time with the expectation to deliver on time still intact.
So I have tried to push back.
-A bug is raised
> If in use case ==> FIX NOW!
>Else ==>can be done in next iteration and is logged as "Not in spec/Functional change".
I thought this may rustle some feathers and hopefully means the uses case would be a little more robust. It also means the actual bugs got higher priority, as I think they should.
No...
Now we just do non-functional iterations where we do "bug fixes" on all the functionality that was never originally asked for.
As there are a few developers (6-12) all on UK rates (not exactly cheap) and one BA (still only UK rates, but only 1), I would think it would make sense to focus the effort on the up front work, hell maybe even hire another "BA" so the development team don’t have to handle code 2,3,4 + times.
It also means the teste (again on UK rates) has to test and then retest every time the change is made... how do you spell D.R.Y???
To say this annoys me is somewhat of an understatement. It is pretty hard to be focused and passionate about what you are doing, knowing full well in only a few hours/days/weeks it will all get thrown out because someone threw together a Use case, with out putting more than 5 minutes thought into it.
More time scoping => less time "bug fixing"*
*i.e. retrofitting missing functionality
Now I know Agile encompasses the ability to "handle change", but never getting the original scope correct... ever, through laziness, is not Agile, it's just software cowboy bollocks.
Unfortunately nothing is going to change. This could be a really good project, even a flag ship project for the company as it is using new exciting tools for the comapny (.Net 3.0, Nhibernate etc) and it would honestly only require the smallest extra bit of effort. But it wont and that’s a shame.
end of yet another rant...
He is in a position where he knows what the application we are building should do and how it should do it. Unfortunately this is only ever communicated to me after I have built the module. He doesnt write the use case so dosen't get a chance to prewarn me.
These changes are raised as bugs (as we only have the concept of bug, no concept of a change request) and so it looks like my code sucks as i have a couple of dozen bugs logged against my name (which is standard across the team). I dont like the idea of my code sucking. While looking through the buglist today, after reading the first 12 and realising that they were either A) Not bugs, but changes or B) not my bugs to fix; I got a little stroppy.
*begin blowing trumpet*
Now, when I get a use case I assume that this is what is required... I know, what an idiot... so I write my unit tests and do the whole Red, Green, Refactor like a good TDD agile boy,
*end blowing trumpet*
however I forget that we only call ourselves agile we are in fact... dreamers.
Huge numbers of tests fail and are left unattended, iteration after iteration... our scope is non existent.. our use case are guesses at what we kinda, maybe want and are completely ok to change at any time with the expectation to deliver on time still intact.
So I have tried to push back.
-A bug is raised
> If in use case ==> FIX NOW!
>Else ==>can be done in next iteration and is logged as "Not in spec/Functional change".
I thought this may rustle some feathers and hopefully means the uses case would be a little more robust. It also means the actual bugs got higher priority, as I think they should.
No...
Now we just do non-functional iterations where we do "bug fixes" on all the functionality that was never originally asked for.
As there are a few developers (6-12) all on UK rates (not exactly cheap) and one BA (still only UK rates, but only 1), I would think it would make sense to focus the effort on the up front work, hell maybe even hire another "BA" so the development team don’t have to handle code 2,3,4 + times.
It also means the teste (again on UK rates) has to test and then retest every time the change is made... how do you spell D.R.Y???
To say this annoys me is somewhat of an understatement. It is pretty hard to be focused and passionate about what you are doing, knowing full well in only a few hours/days/weeks it will all get thrown out because someone threw together a Use case, with out putting more than 5 minutes thought into it.
More time scoping => less time "bug fixing"*
*i.e. retrofitting missing functionality
Now I know Agile encompasses the ability to "handle change", but never getting the original scope correct... ever, through laziness, is not Agile, it's just software cowboy bollocks.
Unfortunately nothing is going to change. This could be a really good project, even a flag ship project for the company as it is using new exciting tools for the comapny (.Net 3.0, Nhibernate etc) and it would honestly only require the smallest extra bit of effort. But it wont and that’s a shame.
end of yet another rant...
Monday, October 1, 2007
Geek speak to Layman terms
Often I forget that the typical developer is not that well rounded; We are geeks and not all us have the best social skills. This article highlighted in a readable way, how you could articulate this to your geek team:
Can Your Team Pass The Elevator Test?
Something I think all employees should be able to do, especially in small agile* software houses in which your end developer may/probably will talk to the end client.
*agile in the true sense not necessarily the methodologies...
Can Your Team Pass The Elevator Test?
Something I think all employees should be able to do, especially in small agile* software houses in which your end developer may/probably will talk to the end client.
*agile in the true sense not necessarily the methodologies...
Monday, July 2, 2007
ICloneable = mess
I have never really taken it consideration of the reasons of why not to use ICloneable. I know not to do it, so have never had any issues. However the current project I am working has object inheriting from a certain base object that implements ICloneable (why? I don’t know).
Now the fact that none (or very few) of the ICloneable methods returned anything other than null, could have been the first sign that it might not be the best interface to implement. Then there are the deep versus shallow clone issues... who know’s what is doing what.. and then the returning of type object. Excellent. :(
Unfortunately it was a Microsoft consultant that apparently suggested using it.
Now we have a non standard clone implementation that some time does deep and sometime does a kind of shallow clone. Yuk. At least some of it is now documented.
As the classes are shared across other projects a cant just go an remove the interface… not that it looks like any one is actually using the method; as it is returning null everywhere… weird.
Now the fact that none (or very few) of the ICloneable methods returned anything other than null, could have been the first sign that it might not be the best interface to implement. Then there are the deep versus shallow clone issues... who know’s what is doing what.. and then the returning of type object. Excellent. :(
Unfortunately it was a Microsoft consultant that apparently suggested using it.
Now we have a non standard clone implementation that some time does deep and sometime does a kind of shallow clone. Yuk. At least some of it is now documented.
As the classes are shared across other projects a cant just go an remove the interface… not that it looks like any one is actually using the method; as it is returning null everywhere… weird.
Tuesday, June 19, 2007
Translating Geek-Speak to Suit-Speak
A colleague and I were talking of the technical debt being incurred on the project we are currently consulting for, when I commented its a bit of a wanky term. CDS quickly reminded me that its a term probably used when a Dev, Architect, consultant is talking to someone in more of a business role and that we have to talk in their terms, i.e. ROI, Debt, Interest, Inflation... i.e "$$$ speak".
It was a good reminder that in times when you need to emphasise crucial points it probably best to talk in a language the other party will actually understand, and therefore "get" the significance of the problem. It is then up to them to make a more informed business decision from there.
It was a good reminder that in times when you need to emphasise crucial points it probably best to talk in a language the other party will actually understand, and therefore "get" the significance of the problem. It is then up to them to make a more informed business decision from there.
Wednesday, May 2, 2007
The eternal fight
It seems like there is always the eternal struggle between dev's and the "non Dev's". You know what i am talking about.
BA's who give innaccurate or incredibly loose requirements yet want you to build a something exactly how they or the customer want it...
PM's who want you to do something that will take 5 weeks to do it in 1 and after you pull uber over time to finish it they then think they were right, it did only take 1 week... and it your fault that it hasnt been tested properly or fully completed...
Sales people who promise the earth and have no idea what nightmares they are putting the team into.... etc etc
And poor old us. The developer gets to shoulder the brunt of it... well so we think. A couple of things happened today that got me thinking, if the average Dev could properly comunicate then alot of these issues could be reduced. Firstly if there is a technical person who will be directly involved in the dev at the time of scope to check everything is on the right track... that may help (in the last 12 months I have been gob smacked how often this doesn't happen). Hell, if the techincal person is presentable and articulate, let him/her come to the scope meetings or be involved in the sales process. Gee that sounds good! In my mind this is a double win, if handled properly. Then the major dev issues come up early, and if they dont, then it was missed by the dev anyway who can no longer point the finger.
Also picking your battles is always something we should be aware of. If you bitch and moan about everything, when i comes to a major issue the PM (or whoever) will just roll their eye's as if to say 'not this again'. Help the non devs to understand the business reason behind your arguement (delivery times & budgets are always good), after all you are suposed to be on the same side!
Its not all doom and gloom. I have been lucky enough to work with great teams such as Neotek, where although conversations got heated, they never got personal and it was always with the intent of making the code, product of processes better. Also the team i work with at Change are a very smart bunch for very different backgrounds where i would like to think we asa collective are learning alot from the others in the team (well I am!).
In short, just because you are a developer doesn't mean you have to be a nerd. Getting people on side with you early on is a big help when things get tight at the tail end of projects (or even just iterations!).
sorry just a bunch of random thoughts, but i thought i would throw them out. :)
BA's who give innaccurate or incredibly loose requirements yet want you to build a something exactly how they or the customer want it...
PM's who want you to do something that will take 5 weeks to do it in 1 and after you pull uber over time to finish it they then think they were right, it did only take 1 week... and it your fault that it hasnt been tested properly or fully completed...
Sales people who promise the earth and have no idea what nightmares they are putting the team into.... etc etc
And poor old us. The developer gets to shoulder the brunt of it... well so we think. A couple of things happened today that got me thinking, if the average Dev could properly comunicate then alot of these issues could be reduced. Firstly if there is a technical person who will be directly involved in the dev at the time of scope to check everything is on the right track... that may help (in the last 12 months I have been gob smacked how often this doesn't happen). Hell, if the techincal person is presentable and articulate, let him/her come to the scope meetings or be involved in the sales process. Gee that sounds good! In my mind this is a double win, if handled properly. Then the major dev issues come up early, and if they dont, then it was missed by the dev anyway who can no longer point the finger.
Also picking your battles is always something we should be aware of. If you bitch and moan about everything, when i comes to a major issue the PM (or whoever) will just roll their eye's as if to say 'not this again'. Help the non devs to understand the business reason behind your arguement (delivery times & budgets are always good), after all you are suposed to be on the same side!
Its not all doom and gloom. I have been lucky enough to work with great teams such as Neotek, where although conversations got heated, they never got personal and it was always with the intent of making the code, product of processes better. Also the team i work with at Change are a very smart bunch for very different backgrounds where i would like to think we asa collective are learning alot from the others in the team (well I am!).
In short, just because you are a developer doesn't mean you have to be a nerd. Getting people on side with you early on is a big help when things get tight at the tail end of projects (or even just iterations!).
sorry just a bunch of random thoughts, but i thought i would throw them out. :)
Subscribe to:
Posts (Atom)
