You know, even with increased context, I still have to say "Yes, they need some kind of source control system," on this one. Now, whether they already have one as part of their already extant practices is a whole other issue, and might not be immediately recognizable to someone outside the process, which is why one actually studies these things for the spec before writing them. Odds are not only do they need it, but they probably do need it now (and, in fact, it probably is already embedded in current practice; having engineers walking all over each other's traces would make things too difficult to believe they don't have one).
Now, the only real question here with a question on the scale is "Do we have the time to include it when we have to trade off twenty other features for it?" And that one comes down to examining the position of where the software you're writing is intended by the customer to fit into their work flow. If all the ap is intended to do is edit flow control block diagrams, and said diagrams are kept on disks in a cabinet that have to be fetched and replaced with changes logged to a seperate piece of groupware, then the SCS isn't part of the ap, but it definitely has to be in place. If, on the other hand, the customer wants the ap to replace the whole fetch-the-disk/log-the-changes/replace-the-disk cycle, then the SCS has to be built into the software.
Maybe I'm unique, but I'm aware that processes extend beyond aps into how the ap is used, and if you're not part of the design process for that too, you're pretty much going to be implimenting useless shit (like Compaq's upcoming call-tracking system, Pulse, designed by useless yard-apes and management-munchers who haven't taken a call in their lives). There is no question hardware engineers need an SCS. There might be a question about whether or not its in a given ap or not. Maybe. In general, it'll be pretty bloody obvious from looking at the customer's spec and processes.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
zaluzianskya and ![[community profile]](https://www.dreamwidth.org/img/silk/identity/community.png)
skylark_photos
no subject
Date: 2002-04-30 03:46 pm (UTC)Now, the only real question here with a question on the scale is "Do we have the time to include it when we have to trade off twenty other features for it?" And that one comes down to examining the position of where the software you're writing is intended by the customer to fit into their work flow. If all the ap is intended to do is edit flow control block diagrams, and said diagrams are kept on disks in a cabinet that have to be fetched and replaced with changes logged to a seperate piece of groupware, then the SCS isn't part of the ap, but it definitely has to be in place. If, on the other hand, the customer wants the ap to replace the whole fetch-the-disk/log-the-changes/replace-the-disk cycle, then the SCS has to be built into the software.
Maybe I'm unique, but I'm aware that processes extend beyond aps into how the ap is used, and if you're not part of the design process for that too, you're pretty much going to be implimenting useless shit (like Compaq's upcoming call-tracking system, Pulse, designed by useless yard-apes and management-munchers who haven't taken a call in their lives). There is no question hardware engineers need an SCS. There might be a question about whether or not its in a given ap or not. Maybe. In general, it'll be pretty bloody obvious from looking at the customer's spec and processes.