So I made an entry recently per a request by a fellow .NETer, that some coworkers have read and noted that it appeared I was commenting on the current project at hand. Strangely enough, even though some might apply directly, I was writing in context of my previous projects. Even though it might not seem like it every single day our current project is actually going very well. By industry standards we're doing ridiculously well! Amid a little turmoil here and there, a little dose of politics, and a little realization that the project is really bigger than originally anticipated everyone is really moving forward, with January really bringing home that point.
With that in mind, and progress being made, the project plans getting straightened out I am offering this current entry as a clarification of my Do and Do Not list. Those that worked with my at specific positions will note where each of these do nots and dos come from.
Do Not List
1. Do not set arbritrary deadlines for a project until full scoping or some type of reasonable expectation the date can be made has been completed by the developers. If you set a date, then continually have to push it back it only increases the negative vibe of the team and creates an environment which will in turn create turnover. Turnover is bad for any software project.
This point is in regards to the dictation of a relatively rich person (He has millions) who would dictate down to the pixel positioning of web pages and dictate down from on high when things should be done. Needless to say things got done when they got done, but it led to a lot of 12 hr days that ended up with the effective loss of 2 senior developer and the orphaning of entire segments of web projects.
2. Do not create specific use cases, business workflows, UML docs, or other docs that are in essence empty and then act like they're fully formed and complete documents. This is a very quick way to erode the enthusiasm of all but the most brazen, determined, and capable software developers (re: What makes a good software developer).
UML docs where presented with some interesting, yet useless design elements for a core product at one place I worked. The UML documents where of no use as everything being done was entirely for customization purposes. Every single element of the project resulted in verbal face to face communication between developers. Something that is by no means bad, but the UML specs where useless in reducing time to deploy, time to build, and reducing ramp up time.
3. Do not create an unworkable environment schedule. Never, and I mean never, I've seen this before, but never, not even when hell freezes over even, ever force developers to work an 8-5 schedule. The second you set a time frame they have to come in you've knocked 10-15% off productivity. The two elements of good productivity are developer chosen hours and a good communication and honesty in hours worked, not setting a schedule for someone to meet.
I once worked in an environment where the hours where between 8am and 5:00pm. This is the quickest way to mess one's life up, lose developers, and cause undue stress. A minor amount of flex time remedies all of this.
4. Do not leave developers without standards unless you want sphagetti code in large volume. No programmer programs the same from day to day, the technologies change, and the development of said individuals changes with personal growth and knowledge.
The largest problem that can occur is a standardless, personally customized, one off solution. These are the hardest, most confusing, and most costly solutions to maintain for a company. I'll name one company I worked for that was notorious for this, Citigroup. Yup, the massive huge corporation had sphagetti EVERYWHERE!!!
…and for the do list, I've decided after the few minutes it took to write this up, that they need no explanation. Simply put, the do items are things to do, so do em'!!!
