Wednesday, January 17, 2007

Do small companies/departments need structure?

This has been a question that has been hitting me home. Some companies think that because they are small, they don't need to spend any time or energy being organized/structured.

By structured/organized technically I mean:

1. Bug Tracking System - That helps developers kill all bugs, which incites them to create less bugs.

2. Project Management System - can be excel, notepad, anything that helps developers manage their time, and managers set priorities, due dates and manage that.

3. Documentation of Code Logic/Business Rules - So that if lead developer dies, and he/she had it all in their head, how in the world would the next lead developer figure out the code/logic and business rules?

4. Common Coding Styles - Including page naming, commenting, indenting. And have this written to train new members, and remind old.

5. Set, Record and aim for Technical Goals not related to specific projects but affect overall success of developers. IT Architecture, Scalability, Updating ColdFusion, Updating databases, Security, etc. Do you just create more code, or do you also work on improving the environmment, universe the code resides?


Maybe the size of the company can dictate the complexity or depth you go to provide solutions to your main needs, but to not provide them sounds like something that should be on the DailyWTF.com

How do you explain the importance of organization/structure to those who think small companies don't need them?

3 comments:

  1. 1. Document the problems. Collect evidence that can prove they are in fact problems.

    2. Find solutions. Not a solution, but plural; many. Collect qualitative and quantitive evidence showing they work. Not 89 page whitepapers, but testimonals, documented time savings from business leaders, etc.

    3. Document you & your team's experience with the problems, and their applicable costs.

    4. Each time you suffer, and after you've documented it, and DEFINATELY after the crisis has ceased (people aren't open minded under stress), suggest ways to improve in the future.

    5. Go the extra mile, and implement solutions. Hopefully this can be an MBO (management by objective) or at least blessed by your manager. For example, in your off time or lunch hour, setup Trac or some other bug system. Have buy in from management at least, and try it out. Make sure this doesn't negatively affect your existing obligations. It's ok if others fail at it, just not you.

    6. Document succes / failure of #5 and be prepared to explain how these fall inline with all your existing evidence.

    7. Don't forget to keep documenting. When done, show that your idea & implementation provided success, positive change, and thank those in management for helping. Use this gained respect to implement additional positive changes. Small bits at a time, not sweeping ones... unless it's in dire need.

    #5 is important. If management tells you buzz off even in the face of overwhelming evidence, either they are dumb, or you are not effectively communicating. In the latter, blog / email for more help. In the former, find another company that isn't scared of change.

    ReplyDelete
  2. Hey Jesse,

    If you'd added a couple of graphs, 400 pages of appendices, an executive summary and bound it nicely you could have sold that comment as a consulting report. Your COMMENT was one of the better POSTS I've read recently - very cool!

    ReplyDelete
  3. I agree, and your comments make sense.

    But what i have done so far, is create a web-based bug tracking/project management solution.

    My department does use it, but doesn't completely understand why they should bother, since they feel small = just telling someone over the phone or email is enough.

    Also i was rather surprised that no one ever checks the coldfusion logs, and low and behold there are millions of bugs going on there.

    These are not bad people, i rather like them, they seemed to be locked in this image of small company/department, so therefore it isn't important to track bugs/projects etc...

    And I am not necessarily pushing extreme levels, but to help us keep track, and allow us to look back in time, and hopefully keep records for new employee's.

    Etc.

    I just get tired sometimes of always have to clean/improve the code/architecture/bug tracking/project management from companies that I work for.

    It would seem rational that they would have some basic system, instead of no system.

    ReplyDelete