Technorati Tags:
StandardsI liked this post by Jeremy D. Miller about what really makes our jobs tough because of others or departments who don’t care to have any sort of process, standards, or feature priority. If only other developers would take the time to care and really work towards coding good quality code, the entire team becomes 5x more productive. This includes telling the business NO at times or slowing down the business (in the case of code & run shops) so that the quality of code and just sanity of work and ability to think while you code, debug errors and TEST!!! is possible so that the entire team and the business works like a well oiled machine, not something that’s hacked which causes a lot of pain. Jeremy points out a list which I know from experience is a direct relation and result to Code & Run shops:
My own list of unacceptable team “Sins”:
Inline Styles – for God sakes, we’re in 2009 people. This is one of the most annoying and inefficient things you can do in a UI. Who wants to update inline styles all over the place. It makes debugging unbearable as well with CSS. Use of this rather than learning and using CSS classes and ids for EVERYTHING that you do to style your UI is just plain laziness. I can’t tolerate it and most good teams I’ve worked on in my career also cannot and will not tolerate it. And if you resist learning tableless design, I feel sorry for you. I’ve found it to now be easier than using tables to control layout which restrict the hell out of me and make my mark-up a complete pile and footprint on the web much bigger for my website. I’m sorry but the argument that “tables are easier” no longer applies to me personally after starting to get real comfortable with divs and other elements lately. Make yourself get into tableless design. You’ll find out in about a month that it’s not that bad after you struggle a bit just like anything else!
No Business Layer (physical and non-physical). Don’t have a BL project? Shame on you…not good. Don’t have BL classes related to entities? This is also not acceptable. Putting all your basically business layer type methods into one class which basically serves as your BL, again is not acceptable. There are about 100 obvious reasons why this is not ok to skip having a BL in your applications…makes life for all developers using it hell. In fact I just cannot stand it when I don’t see a BL in mid-to-large applications. It just boggles my mind. It also renders your application non-unit testable. I don’t have to go on to explain this, it’s obvious. If you’re too lazy to stub one out, not cool. The mindset should not be “does this application really need that much separation”. The mindset should be SOLID and “I don’t care if it doesn’t need it now, but will it in the future? We don’t know but at least create the separation for extensibility regardless”.
No XML or C# comments – again, laziness. And I don’t buy into “the business wanted it now, so I did not have time”. That’s bogus. Tell the business tough, I need some time to code well and test my damn code. The business CAN wait. If you think that you have to run to every person who calls up and wants something NOW, then you have definitely not had experience in other environments which would look at this as complete chaos and completely inefficient and ridiculous. The business should not drive stupidity and hacky code. That’s not what they should be paying you to do for them with these unrealistic deadlines/expectations.
No Source Control at All – that’s self explanatory. It’s a HUGE burden to the development environment for a ton of reasons and it does NOT matter how big the team is.
No Source Control Check-in Commenting or Sufficient Commenting –and when I say non-sufficient, I’m talking about comments like “updated page”, “changed x method”. Be thorough in those comments. Nobody wants to look at every piece of code you updated in order to “see what changed”. I hear developers give this excuse when not putting in comments saying “just look at the diff file”. Hey, guess what, other developers do not have the time to review your entire change set idiot. So put in a comment that explains the change set and a decent summary (3-4 lines or whatever) to allow someone glancing at it to get a little more than “added a feature”. Give 3-4 sentences per check-in. Trust me, it’s not that much time consuming and it’s a disrespect to others on the team. You’re not the only one using that codebase and others need to know quickly what each change set represents when looking at history to decide which change sets may pertain to them or affect them
Not Checking Code Into Source Control Often – who wants to merge a ton of sh%% later 2-3 weeks or a month from now when you are just about to deploy to QA. The entire point of source control is to get latest and to work against that codebase. If fellow developers are not checking in often, what’s the point of using source control then. You should not worry about your code being perfect. That’s not what source control is about. Sure, make sure it’s not going to break when others compile your code and make sure you’re not introducing show stopping errors. But otherwise stop freaking out and just check in often. It’s not that bad really.
Developers Constantly Checking in Breaking Code – if you do not have continuous integration using Cruise Control, you need to start NOW for the benefit of you and the entire team.
These are not “picky”. These are effective requirements for a development team to function efficiently which correlates to developers enjoying what they do, and developers able to meet deadlines and to produce code that is reliable for the business later on because the process has standards defined and expectations defined for the team and system as a whole.
It’s called SANITY, instead of Code & Run CHOAS. It saves a huge amount of time for all if these standards/expectations/practices are in place. All the points above together adds value to the team, the code base, and maintenance thereof. I can say these things from experience being in many environments, so this is not just rambling or rants here. It’s common sense and it’s called having good teamwork, a good process, and good standards in any development environment tiny or big…doesn’t matter.
