Loading ...
Sorry, an error occurred while loading the content.
 

Re: [XP] Realising my mistakes with XP

Expand Messages
  • Ron Jeffries
    Hello Psychie, Thanks for writing. Your note was long, and I ll just excerpt and comment on bits of it. Sort of a chat. I d suggest that you might want to just
    Message 1 of 40 , Aug 2, 2006
      Hello Psychie,

      Thanks for writing. Your note was long, and I'll just excerpt and
      comment on bits of it. Sort of a chat. I'd suggest that you might
      want to just quote and respond to bits and pieces, so this exchange
      doesn't get any more like a book than it already is. I tend to run
      on, so you should probably try to be more ruthless with the
      scissors.

      On Tuesday, August 1, 2006, at 3:19:26 AM, you wrote, in part:

      > First of all, thank you for being so welcoming and inviting me to share my
      > situation properly. My plan in joining the list was to ask questions which
      > were as specific as possible, so that I wouldn't take up too much of
      > anyone's time. I mainly observed the discussions on the list which seemed to
      > be about more important topics than mine so I'm pleasantly surprised and
      > delighted you'd be willing to know more.

      Specific questions are easier, but with more context, we can do
      better. At least we hope we can. ;->

      > Myself an two friends are trying to start up an IT company. ...

      > Our first project is to provide the IT infrastructure for a retail outlet.
      > ...

      Others have mentioned that some kind of open source starting point
      might have been "better". I understand the desire to program all
      solutions. I've also come to understand that things that look easy
      to me at the beginning usually turn out to be much larger, and often
      more complex, than I originally thought.

      > For the Demo, I basically hacked for about a week taking short naps
      > whenever I could (the usual programmer stuff) and came out with something
      > that looked like it did something similar to what was required. By February
      > it looked like we were going to get the deal but we wouldn't know for sure
      > till March. I was sick of Hacking code (well I loved the hacking but was
      > sick of the lack of structure and amount of bugs it resulted in) so I
      > decided it was time for a change. I had a month.

      I've come to believe that I never prosper from this mode of working
      for very long. I produce ugly code that won't sustain a longer
      effort. I might "hack" for a day to find out how to learn something,
      but even then, taking a very short time to learn, and taking a more
      orderly test-driven approach helps me.

      This did not come naturally to me. I was driven to it by a desire to
      understand this Agile stuff and as many as I could of the ideas that
      are part of it. I had the luxury of being able to treat all my code
      as experimental, and I'm sure it would have been more difficult had
      I been under deadline. That said, this orderly way of working was,
      for me, well worth learning.

      > I was considering checking out Ruby on Rails to see what all the hype was
      > about. ...

      > After that, I decided it was time to get into version control ...

      Sounds to me as if these may have been a bit of a digression for
      you, with respect to the actual project. Perhaps going ahead without
      customer approval would have been better ... it's hard to say. What
      do you think, looking back? We can't change the past, but we can use
      it to guide what we do today.

      I am often attracted by new things and veer from the path of
      accomplishing what I want to. Making a specific time of day to do
      actual work seems to help me a bit, but my ability to be
      undisciplined is quite strong. I hope you can control your
      undisciplined side better than I can.

      > During the month of waiting I was designing the database whenever I got the
      > chance or came up with a new requirement. I was working from some user story
      > cards I wrote myself after showing the demo as I had a pretty good idea of
      > what the customer wanted after showing him the demo.

      Sounds good ...

      > I believe this (i.e. trying to design the database for the entire system
      > first) was probably my first mistake.

      My own practice is to hold off on the database, other than sort of
      sketching it. What better things do you think might have happened
      had you spent less time on the DB?

      > ... I finalised the design and went about my new
      > XP ways. I went back to the customer, wrote some scenarios on some index
      > cards and used these to produce my understanding of what 'User Stories'
      > actually are. I wasn't too sure so I spent a while looking for tutorials
      > specifically explaining User Stories. I laid them out so that I could
      > visualise the system and numbered them all in order of priority. I know that
      > they are only supposed to be numbered from 1 to 5 but for now I just
      > numbered them in the order I was going to implement the functionality, until
      > I knew for sure I was doing things correctly and that the stories were
      > valid. I didn't break them down into engineering task either for the same
      > reasons.

      > This was probably mistake number 2. I had read that XP could be started by
      > only applying some of the ideas and I needed to get going asap so I risked
      > it.

      Today I'm more concerned with getting the stories small than I am
      with using a strict breakdown of engineering tasks. I think the
      tasks are a good design step that cause us to think, but that beyond
      that they are a distraction, especially for a one-person "team".

      There are some practices that I wouldn't do without, but the task
      breakdown probably isn't one of them for me, these days.

      > I wanted to get to a certain stage of functionality and to get used to all
      > of the new methods/tools I had started using.

      I'm thinking that there were perhaps too many methods and tools all
      at once. What is your feeling at this point?

      > As I hadn't any engineering
      > tasks, I couldn't assign them points so instead, in order to try to measure
      > my progress per iteration, I recorded on each card how many days it took to
      > implement that particular story. These of course would all be high as most
      > of what I was doing (e.g. the framework syntax, the unit testing, the story
      > cards etc...) was new to me. I also skipped the CRC cards for now as, to be
      > honest, I was no OOP expert either so I wanted to learn a bit more to give
      > me the confidence to do the cards properly (although now I see that this was
      > another mistake as the cards were initially developed as a way to actually
      > help in the understanding if OOP, so my logic was backwards). I was
      > basically writing unit tests directly from the User Story cards, and then
      > writing code from there.

      This all seems fine to me. I would assign points or other estimates
      directly to stories, however, using the tasks at most as a
      guideline. I feel that focusing too directly on tasks, rather than
      stories, tends to encourage me to over build things.

      An analogy is the database design. There's not much point in doing
      detailed design on tables or fields that I'm not going to use for a
      while. I like to sketch in, oh, there'll be some kind of a table of
      products here to join in, but that's usually enough. If I start
      figuring out every field and format, that's usually too much.

      Same with tasks and auxiliary practices. It's easy for me to get all
      involved in coming up with a good scheme for code management instead
      of working on the project. Running a nightly backup might be all the
      code management I really need. And so on ...

      > ... [Testing Trials] ... I have since realised how to unit test
      > controllers and so will be doing this first in my next iteration.

      Sounds like you did a lot of learning here. That's good, and it'll
      serve you in the longer term. Maybe even on this project: though
      your progress has been slower than you'd like, we can at least hope
      that the product will be much better than it would have been had you
      not done all this learning.

      What is your thoughtful view on that? Looking back, has the learning
      paid off in this product?

      > My weekly iteration plan was also non-existent due to the fact that I was
      > moving so slowly with respect to the scope of the project and the time left
      > to the first implementation. I was getting an average of one story coded
      > every two days, but needed to do two per day in order to meet the deadline.

      Here's a key issue ...

      > Naturally I cut off the non-essential stories and showed the customer what I
      > can only describe as a "demo of progress", i.e. it showed what stage the
      > system was at without actually doing all of the work in the background.

      ... and a good step. I'd want the customer to know, always, just
      where we were, and to use his impatience as a goad to keep me on
      track. I'd want to be really clear in my own mind about how fast I
      could go. If it's two days per story, and that's as good as I think
      I'm going to get, it can only help to be clear about that with
      myself, and with the customer.

      > Luckily he had more to add at this stage and if I had gone much further I
      > would have had some redundant work. This showed me how important being in
      > constant contact with the customer is, however since I was moving so slowly
      > I was afraid the customer would lose faith. Even so, not keeping in constant
      > was indeed a big mistake. How do you suggest keeping in contact with the
      > customer when progress is embarrassingly slow?

      Openly and clearly. Progress is what it is. Being clear about it is
      the only honest thing to do, in my opinion. If I'm clear about how
      fast I'm going, and I'm showing real progress, that's my best chance
      for the customer to come to trust me and pay to keep me going. If I
      keep promising the moon and delivering very little, that will build
      distrust and end in disaster.

      I need to come to understand what I can do, and what I will do, and
      then make sure the customer understands that. That doesn't mean that
      I'll dump my every personal problem or internal fears on them. It
      does mean that I'll say something like "With stories this size, it's
      taking me about two days to do each one. I think I can sustain that
      pace, and though I'll try to go faster, I think we should plan based
      on what I'm actually accomplishing, not what I hope to accomplish."

      > Every time I'd try to do something new I'd go and read a bit more about it
      > first so naturally my progress was slow. I also started to look at tool to
      > help from a project management point of view. I spent a fair while looking
      > into bug/request trackers etc, and have finally settled on Trac, although I
      > haven't actually set it up yet. I spent too much time on this but thought if
      > I had it up and running I could plan, assign and view the progress of
      > non-software related tasks for my two partners as well as myself. This way I
      > could maximise the overall flow of work done and give myself the extra drive
      > to keep up. It's hard to get a start-up going and work on a project at the
      > same time if you like sleeping and eating.

      Sleeping and eating are important. They keep us fit and alert.

      I wouldn't bother with Trac or the equivalent. A deck of cards stuck
      to the wall or laid on the table is easier to use, more flexible,
      and saves a lot of time fiddling with a tool that isn't central to
      the project.

      > At present the project is two months overdue as the initial agreement was
      > to have the preliminary system in by June 1st. This is not all my fault
      > however as the customer is very slow in giving me the stock data for the
      > system. I sent him a spreadsheet containing worksheets representing tables
      > in the database with the fields I wanted to be filled in, along with some
      > sample data to show what I meant. I left out any database association fields
      > of course in order to avoid confusion. Naturally, even though I told him not
      > to, he added fields he thought were needed and sent them back to me half
      > filled in three weeks ago. Along with these he sent me his supplier
      > catalogues and asked me to do the data entry myself instead as it's too
      > inconvenient for him. He expected to be able to just give me the raw data
      > and it would get sucked up into the system as this is what our competition
      > was offering to do. I explained how, since our version of the system was so
      > customised to his needs (and our competition's system wasn't) that I needed
      > the data in a specific way in order for the system to function the way he
      > wanted, but ended up agreeing to do as much of the data entry as I could
      > myself. Perhaps I will get one of my two partners to do this but I'm worried
      > that if the customer can't get it right and he understands everything about
      > the attributes of the stock data, then I doubt if one of the guys will be
      > more efficient. At least I know the workings of the system so perhaps it
      > would be best for me to do so. Another possible mistake???

      It might be best. But it needs to factor into the expectations on
      when things will be done. It is also possible that someone else
      could do some of this, perhaps even a randomly chosen high school
      student or something.

      The notion of "two months overdue" concerns me ...

      > The launch date is now September 1st and I'm just finishing the point of
      > sale module now.

      ... and this concerns me too.

      There's some true minimum of functionality that the customer can
      use, and you are producing functionality at some rate. Sounds like
      we don't know either of those very well, but maybe it's "one story
      every two days, and we absolutely must have these".

      That number of stories, and that rate of production tells us what
      the date really is. It's clearly not June 1. It may or may not be
      September 1.

      I'd really want to be knowing when I'm projected to be done, based
      on actual progress and actual need. That's very different from when
      I want to be done, hope to be done, or have promised to be done.

      > I should have handled things better but in fairness I've
      > also been trying to get the legal side of things sorted. Unfortunately I'm
      > the kind of person that likes to be involved in all aspects of the project
      > so that I can make sure it's being done right, (or at least what I think is
      > right). Does anyone else have this problem where you give people jobs to do
      > but they never do it the way you told / showed them?

      Yes. Everyone has. The trick is to let them do it better.

      > Perhaps I shouldn't ... In fact, I don't even know any
      > real developers, so it makes things even more difficult. So basically, as
      > far as the software development life-cycle is concerned, I'm a one man show
      > until I get something finished.

      I'd think that almost anywhere there are people to talk with, and of
      course the cyber folks can be helpful too. With all due respect, it
      seems to me that the "one man" aspects of your situation aren't
      helping you as much as they might. That could just be me, thinking
      about me, of course, but I work much better when I have someone to
      play with.

      > By the way, thanks to all for their help and advice on the last post. And
      > thanks to Ron for the links. The range of advice given in the replies would
      > cover a good deal of the problems described above, especially on the
      > database end, and the only information I gave was that I had started with
      > the database design. Therefore, I'm very interested to see what comes out
      > from this post.

      Let's hope you remain interested after things begin to happen. I
      look forward to hearing from the other 5000 people on the list ...

      Ron Jeffries
      www.XProgramming.com
      Do as you will, try to do it well. That's what I do.
    • Psychie Naill
      Cheers Tony, Will do. Psychie. [Non-text portions of this message have been removed]
      Message 40 of 40 , Aug 9, 2006
        Cheers Tony,

        Will do.

        Psychie.


        [Non-text portions of this message have been removed]
      Your message has been successfully submitted and would be delivered to recipients shortly.