---- START NEW MESSAGE --- Received: from cherry.ease.lsoft.com [209.119.0.109] by dpmail10.doteasy.com with ESMTP (SMTPD32-8.05) id A8A25B1E008E; Thu, 29 Jan 2004 05:20:34 -0800 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.00CC27D3@cherry.ease.lsoft.com>; Thu, 29 Jan 2004 8:20:21 -0500 Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (LISTSERV-TCP/IP release 1.8e) with spool id 2959 for PICLIST@MITVMA.MIT.EDU; Thu, 29 Jan 2004 08:20:11 -0500 Received: from MITVMA (NJE origin SMTP@MITVMA) by MITVMA.MIT.EDU (LMail V1.2d/1.8d) with BSMTP id 9081; Thu, 29 Jan 2004 08:20:02 -0500 Received: from front3.chartermi.net [24.213.60.109] by mitvma.mit.edu (IBM VM SMTP Level 430) via TCP with SMTP ; Thu, 29 Jan 2004 08:20:02 EST X-Comment: mitvma.mit.edu: Mail was sent by front3.chartermi.net Received: from [66.188.8.48] (HELO BrianBoru) by front3.chartermi.net (CommuniGate Pro SMTP 4.0.6) with SMTP id 539277991; Thu, 29 Jan 2004 08:20:04 -0500 References: <2193429B07D9914D97216EBBAA6AB8BD1A0509@whitlam.corp.gli.com.au> <5.2.0.9.2.20040129073858.01554480@mail.cedar.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Message-ID: <006001c3e66a$99436ac0$090044c0@BrianBoru> Date: Thu, 29 Jan 2004 08:19:59 -0500 Reply-To: pic microcontroller discussion list Sender: pic microcontroller discussion list From: "John J. McDonough" Organization: IS-SixSigma, Inc. Subject: Re: [PIC:] Process Comments: cc: dvanhorn@CEDAR.NET To: PICLIST@MITVMA.MIT.EDU Precedence: list X-RCPT-TO: Status: U X-UIDL: 371856254 Well, you said it in the title ... it's not the tools, it's the process. Us tech types often get so enamoured of the latest and greatest tools that we forget what it is we're trying to use the tools for. The problem is that you need to have the process down before you can even know what tools will be helpful. And I would suggest that, in general, fancy tools aren't all that much help in a 1-3 person team anyway. The place they can make a huge difference is on large teams where you are constantly tripping over yourself. But with a small team, it's hard to get your head around the idea of process. The small team tends to deny that any sort of process discipline is helpful. But the software development process isn't much different whether its VB or assembler. A little bit of process discipline goes a long way to making us a lot more effective. I don't know your team and it's particular issues, but I know where most teams get into trouble. The first stumbling point is requirements. Often we don't get a detailed enough set of requirements. This is the most costly place we trip up, because a slight misunderstanding causes a large amount of work later on. One way to improve the requirements is to describe the tests before you move on and consider the requirements "done". Being able to describe how you are going to test a requirement is a huge help to making sure the requirement is specific enough. It also describes the requirement in a slightly different way which gives your customer an opportunity to see whether you heard what he thought he said. The other issue with requirements is believing that they are "done". The trouble with requirements is that, as you move through the design process, you learn more and you get more insight into the requirements. This often means they change. Unless you have a process in place to recognize those changes and account for them throughout the project, you tend to shrug them off until they come back to bite you later, when they are a lot harder to fix. The other thing we want to blow by in small teams is going through the discipline of a somewhat formal design and making sure that the design artifacts are all traceable back to the requirements, and all the requirements are implemented in the design. What I don't think smaller teams "get" is that all these design documents aren't nearly as important as the process of writing them in the first place. With our tool bent we spend more time worrying about formats and appearance, when the important thing is the thought process. If we have a sufficiently detailed design and good traceability, almost any monkey off the street can grok out the code. And in this case, debugging, although it will continue to exist, will be a tiny part of the effort, should be well under 5%. Of course, there is a huge side effect to this. If debugging is tiny, your ability to estimate accurately will be greatly improved. I'm sure this doesn't make much sense. However, there is plenty of data, from SEI, Boehm and others, that the more time you spend up front on requirements and design, the less time you spend on the total project. I've seen this myself, although in the large team context. It does, however, eventually kill the whole macho programmer thing that small shops often thrive on. Once your projects are predictable, so are your manpower needs. The ultimate outcome is that programmers can work 8 hour days, which does tarnish a lot of the mystique of being a programmer. --McD ----- Original Message ----- From: "Dave VanHorn" To: Sent: Thursday, January 29, 2004 7:44 AM Subject: [PIC:] Process > Ok, this isn't really a PIC question, as many of you know, I'm a charter > member of the dark side, programming in assembler, on AVRs. > > However, this question is processor irrelevant, and I think PIC will reach > the most people. > > So here goes. > > I spend too much time debugging. > Why? > I know, at the bottom, it's sloppy technique. > Let's face it, almost every time the code doesn't do what it's supposed to > to, it's because we did something stupid. > > The question is, how can I improve? > I know there are books out there, but they all seem geared twoard large > teams in high level languages, and I basically never go there. > I normally work on 1-3 person teams, in assembler. > This means that I am locked out of a lot of tools in the first place, > because they are C-centric. > It's no use arguing high level languages at me, I am frequently scraping > the last cycle in processor bound routines, and I simply can't pay that > penalty. > > So, what is there, for guys like me? > > -- > http://www.piclist.com hint: The PICList is archived three different > ways. See http://www.piclist.com/#archives for details. > -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details. .