Tuesday, July 13, 2010

Change: Incrementally Making Things Better (Part 5)

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/change_incrementally_making_things_better_part_5.htm]

  • Part 1 (Intro)
  • Part 2
  • Part 3
  • Part 4
  • Part 5
  • Part 6

    STEP: Implement it in small, practical stepsAt a certain point, you just need to jump into the arena and get your hands messy. After all the meetings, word docs, PowerPoint slides, business ROIs, and cheering sessions, eventually someone needs to actually start writing code or changing scripts or procuring a tool so that the change actually happens. PowerPoint decks are not change; working C# code running on other people's machines is.Be practical - you must meet people where they're at. You want to give a drowning man a life preserver, not swimming instructions.
    • Be prepared to build the prototype yourself - You may not be able to wait for your manager to give you schedule time or for the PMO to hire contractors to build it - necessity may demand that you start something yourself (this probably means nights or weekends). If the team thinks it has potential, you have a good chance of handing it off to other developers and letting them run with it.
    • Your deliverable must be something concrete - Tools, approval emails from management, scripts, or code blocks are all concrete. An email with a link to a "cool" article, or a suggestion of what we "should do if we only had time", is not concrete - it will no more feed your team's need for improvement than an article on restaurants will feed a hungry family.
    • Make it work - If you're making a tool, make it easily available (say, publish a working version to a public share - don't require them to compile the source code themselves), make it run on their machine, and ideally give it default config values so that it does something useful right off the bat. From the time Kurt agrees to look at your tool and you arrive at his desk, you have minutes to download it onto his machine, click a single icon or dos command, and have him see the pain that the tool saves him from.
    • Start small, and continually add value in incremental steps - Have some deliverable every week. If you're working 20 hours on a project, there's got to be something to show for it. Avoid the "just give me 3 months and I'll give you the perfect solution," because they'll never give you a blank check for 3 months. Even if they do (say you've built up a great reputation with previous successes, so management risks big schedule time on your ideas), some big emergency will interrupt you 2 weeks in. You'll be constantly distracted with the "urgent" so you'll never get to actually do the "important". You're 3-month salvation project will lay in mothballs, taking some of your credibility with it.
    • Don't be paralyzed by perfection. I.e., "perfect is the enemy of done". An imperfect solution that actually does something is adding more value (and relieving more pain) than the perfect solution that never got built. Consider building a quick "band-aid" or "throw-away" solution now to stop the bleeding and then building that perfect solution in 6 months when the schedule magically opens up and you have all the time in the world (yes, this is sarcasm).
    • Don't be paralyzed by "coolness". Lots of developers like "cool" new technologies. However, such technologies often have risk and learning curves - which may mean that you only have enough time to come up-to-speed with the tech, but not to actually build something useful with it. Many of the infrastructure problems that most shops face have already been solved with older technology - look at classic books written in the 1990's like Code Complete and The Pragmatic Programmers, and ask yourself - how many of those good practices is a suffering department still lacking? Nightly builds, automated deployment, unit tests, modular design, layers - they were all done with over 10-year old technologies. If some cool new technology saves your day - great - but don't limit yourself to it. Sometimes a good old fashioned xml file and console app plumbing is sufficient to save your infrastructure.
    Keep in mind that you must do all of this while still getting your Boss's priorities done. You cannot just "go rogue" and abandon your official responsibilities to do a bunch of research and innovation.

    NEXT:  Part 6



    1 comment:

    1. Trong khi nhiều ghế văn phòng cung cấp đệm trên ghế, một số cung cấp đệm thêm vào cánh tay, tựa đầu, lưng và nhiều hơn nữa.Siêu thị nội thất bán ghế xoay văn phòng ở Gò Vấp
      Mặc dù ghế có tay đệm hỗ trợ thường cung cấp thêm và thoải mái, một ghế làm việc mà không có tay vịn có thể phù hợp nhất với nhu cầu cụ thể của bạn.Tư vấn mua ghế xoay văn phòng tại tpHCM
      Lựa chọn mua ghế làm việc cho văn phòng công ty nhân viên. Nên bạn cần quan tâm đênXu hướng chọn mua mẫu ghế văn phòng
      Bạn đang có nhu cầu chọn mua mẫu ghế làm việc cho nhân viên văn phòng. Và lựa chọn cácTiêu chí nên biết chọn mua ghế văn phòng
      Cần mua loại ghế văn phòng nào cho công ty doanh nghiệp tại văn phòng.Sâu đây là các vần đềNên lựa chọn mua ghế văn phòng nào hợp với bạn
      Nhu cầu chọn mua bàn làm viẹc tạo đâu để đáp ứng nhu cầu mua và làm việc tại các công ty văn phòng. Nên viêcnjBạn nên chọn mua loại ghế văn phòng nào