In Search Of

a blog about software projects...

  • Real World Developer Manifesto

    • 20 Dec 2011
    • 1 Response
    •  views
    • software development
    • Edit
    • Delete
    • Tags
    • Autopost

    Real World developers prefer:

    • Getting things done over sitting in meetings, but understand that communication is important.
    • Working code over extensive documentation, but understand that government regulations, and product sustainability require a rational approach to documentation.
    • Requirements that describe business value over requirements that prescribe implementation vectors, but understand that the customer often can only express requirements in concrete examples based on his or her experience.
    • Practices that work HERE over elaborate methodologies that were designed elsewhere, but understand that some established repeatable practice is beneficial.

    Read the rest of this post »

    • Tweet
  • Is It Me?

    • 13 Dec 2011
    • 0 Responses
    •  views
    • communication leadership negativity
    • Edit
    • Delete
    • Tags
    • Autopost

    Occasionally - I will get into a conflict with someone, and I don't know why. When I look back at the conversation, what I remember, it becomes apparent that either I baited someone into an argument, or vice versa.

    Sometimes this happens because I attach connotative meaning to something someone says because I think I know what he or she means. Other times I have some history that comes to bear, so I project that history on top of something. In either case, the conversation becomes broken, and communication stops.

    Inevitably, it turns out that I have tried to read meaning into something that someone didn't intend, or maybe they did, but didn't expect anyone to pick up on it, and so they are embarrassed that it was noticeable. Perhaps the best thing to do is to act as if everyone communicates superficially, and straight, and to simply communicate back at that level. To not read anything into other peoples statements and questions.

    By ignoring perceived hidden agendas, ulterior motives, personal biases - my communication becomes straight; to the point. Not balled up in other peoples issues. As an analyst, I tend to try (too hard) to unwind this stuff and sometimes get wrapped around the axle in doing so. I react to my perceptions of others' motive and agendas, rather than simply communicating facts and my opinions (when asked), I let my opinions of others interfere with communication.

    • Tweet
  • Estimation Purposes

    • 12 Dec 2011
    • 0 Responses
    •  views
    • estimates trust
    • Edit
    • Delete
    • Tags
    • Autopost

    Mike Cottmeyer's post about How to Think About Estimating is freakin' brilliant. I applaud him for speaking his mind, and telling us how professional software delivery can get done.

    Why?  Because he gets down to the guts of why estimation is hard for so many teams, and while it seems to me that half of the agile community is ready to give up on estimation altogether, Mike hangs in there with a reminder that the customer has a right to a rational contemplation of cost and delivery schedule.  Why - because they are paying the bill.  Period.  Maybe there are cases (startups, or companies with more money that sense), where the budget or the schedule are not constraining the delivery of software, where the customer doesn't ask how much or how long.  I have never been in that situation.

    Read the rest of this post »

    • Tweet
  • 10x Software Productivity Variance - What?

    • 12 Dec 2011
    • 0 Responses
    •  views
    • Productivity Software development frameworks heroes problem solving tools
    • Edit
    • Delete
    • Tags
    • Autopost

    This article by Larry O'Brien got me fired up...

    Not because I disagree with the notion of some software developer being 10 times as "fast" delivering software as the average developer. Because that is not what productivity means. Productivity is about leverage, not speed.

    Read the rest of this post »

    • Tweet
  • Team Vs. Skill

    • 6 Dec 2011
    • 0 Responses
    •  views
    • team
    • Edit
    • Delete
    • Tags
    • Autopost

    Here is a team formation anti-pattern that I have observed recently: Dividing the team along the lines of Skillset.

    Grouping teams along skill lines, inherently sets up competition rather than collaboration. This is especially true (in my experience) in software designed, where skills vary by "architectural layer" so subteams form at the layer level. Each subteam develops some ego: my layer/skill is important, our practices are immutable.

    Read the rest of this post »

    • Tweet
  • About

    Rich is very interested in ideas which make it easier for software teams to be more productive, and for software projects to be more predictable.

    Rich is also very involved in Christian ministry and charity work, and ideas that make ministry more effective.

    8951 Views
  • Archive

    • 2012 (23)
      • May (3)
      • April (4)
      • March (5)
      • February (5)
      • January (6)
    • 2011 (99)
      • December (5)
      • November (6)
      • October (12)
      • September (11)
      • August (13)
      • July (8)
      • June (11)
      • May (3)
      • April (7)
      • March (9)
      • February (9)
      • January (5)
    • 2010 (22)
      • November (1)
      • September (1)
      • June (3)
      • May (17)

    Get Updates

    Follow this Space »
    You're following this Space (Edit)
    You're a contributor here (Edit)
    This is your Space (Edit)
    Follow by email »
    Get the latest updates in your email box automatically.
    Loading...
    Subscribe via RSS
    TwitterLinkedIn
    Freeware Tools
    Add blog to our blog directory. Blog Directory
  • Sites I Like

    • Management Skills Blog
    • Herding Cats Blog
    • Seth Godin's Blog