Yellow Fang
Legendary Member
- Location
- Reading
Are there any other programmers on here? If so, what are your opinions on the complete software lifecycle? I did an HND in software engineering twenty years ago. We learnt about Yourdon's methodology and breaking down software into processes and modules, writing pseudocode descriptions of modules and data dictionaries.
The first job I got was because the department manager was a convert to software engineering practices. They were trying to introduce it to their department. They developed aircraft simulator visual systems· Personally, I blame having to use software engineering practices for getting me the sack in that job. I was given the task for writing a diagnostics package for testing one of the processing units. I wrote iteration after iteration of the design documents, which would get picked over and bounced back by the senior engineers. I could never understand what the software actually did because I wasn't allowed to to start coding. When redundancies came around, I was first on the list.
I've never been able to understand software until I've started coding it. Design specs just bounce off my retinas. At that company, they were working to introduce the V model. They'd do the user requirements, review them, progress to the architectural design, detailed design, implementation then back up the other side with unit testing, validation against the equivalent design specs. Has this ever worked in history? The way it usually seemed to work was that initially someone would draw a design, and possibly do some pseudocode. Then people would discover mistakes in the design or think of a better way of doing it. By rights, they should go back and rectify the design, but instead they just implement it in the code. Before you knew it, the code and design documents would bear no relation. In one of my other jobs, I was barely allowed to touch the software, but I was allowed to modify the design so it reflected the implementation. Writing pseudo-code never seems to make much sense to me anyway. High level software languages are pretty much the same as pseudo-code. Having to write detailed design documents just meant having to duplicate work. Nobody ever reads the design documents, and if they do, they don't understand them. I don't think most engineers really start to understand the code until they start messing about with it.
One of my other jobs was writing and testing software for aircraft engine controllers. As it was safety critical, all the design specs were totally unambiguous, and everything had to be rigorously tested against the design documents. The designs were different to anything I'd studied up to then. Basically, they were logic diagrams, resembling circuit diagrams. The engineer from Pratt & Witney would send us the diagrams, we would implement and test them. Then Pratt & Witney would do their own tests back in Canada. Then we'd get another set of diagrams. It seems like everything was thoroughly designed and tested like you would hope, but basically what we were doing was compiling the designs the Pratt & Witney guy was giving us. If there had been a design package that could have compiled his designs into code, he would have used that instead of us. So basically, the Pratt & Witney engineer was hacking the designs until it worked.
My last job was not safety critical or high volume, so most of us just wrote code, tested it to our own satisfaction and sent it to the customer. If they were unhappy with it, we'd fix it. Sounds really unprofessional, but we never had any requirements specifications, and often the customer weren't sure what they really wanted anyway. It seemed to be that the more important the project, the less documentation there was for it. We had functional specs and software specs for some of the products. The functional specs were there to let the project engineers to know how to configure the systems. The software specs were to enable following software engineers to compile the software. They usually did have a few diagrams, which sometimes I updated for the good of my soul, but nobody ever read them. Generally I used the comms protocol documents to write the softwware.
Now I hear UML and object oriented design is all the thing, and Yourdons methodology and similar methodologies are consigned to the scrapheap. I've read about UML but I haven't used it. If it actually helps, then that's ok. If all it does is duplicate work and create inconsitency then I'm not sure it's a good thing. If a design tool actually:
then I think it would be worthwhile. Otherwise I don't.
The first job I got was because the department manager was a convert to software engineering practices. They were trying to introduce it to their department. They developed aircraft simulator visual systems· Personally, I blame having to use software engineering practices for getting me the sack in that job. I was given the task for writing a diagnostics package for testing one of the processing units. I wrote iteration after iteration of the design documents, which would get picked over and bounced back by the senior engineers. I could never understand what the software actually did because I wasn't allowed to to start coding. When redundancies came around, I was first on the list.
I've never been able to understand software until I've started coding it. Design specs just bounce off my retinas. At that company, they were working to introduce the V model. They'd do the user requirements, review them, progress to the architectural design, detailed design, implementation then back up the other side with unit testing, validation against the equivalent design specs. Has this ever worked in history? The way it usually seemed to work was that initially someone would draw a design, and possibly do some pseudocode. Then people would discover mistakes in the design or think of a better way of doing it. By rights, they should go back and rectify the design, but instead they just implement it in the code. Before you knew it, the code and design documents would bear no relation. In one of my other jobs, I was barely allowed to touch the software, but I was allowed to modify the design so it reflected the implementation. Writing pseudo-code never seems to make much sense to me anyway. High level software languages are pretty much the same as pseudo-code. Having to write detailed design documents just meant having to duplicate work. Nobody ever reads the design documents, and if they do, they don't understand them. I don't think most engineers really start to understand the code until they start messing about with it.
One of my other jobs was writing and testing software for aircraft engine controllers. As it was safety critical, all the design specs were totally unambiguous, and everything had to be rigorously tested against the design documents. The designs were different to anything I'd studied up to then. Basically, they were logic diagrams, resembling circuit diagrams. The engineer from Pratt & Witney would send us the diagrams, we would implement and test them. Then Pratt & Witney would do their own tests back in Canada. Then we'd get another set of diagrams. It seems like everything was thoroughly designed and tested like you would hope, but basically what we were doing was compiling the designs the Pratt & Witney guy was giving us. If there had been a design package that could have compiled his designs into code, he would have used that instead of us. So basically, the Pratt & Witney engineer was hacking the designs until it worked.
My last job was not safety critical or high volume, so most of us just wrote code, tested it to our own satisfaction and sent it to the customer. If they were unhappy with it, we'd fix it. Sounds really unprofessional, but we never had any requirements specifications, and often the customer weren't sure what they really wanted anyway. It seemed to be that the more important the project, the less documentation there was for it. We had functional specs and software specs for some of the products. The functional specs were there to let the project engineers to know how to configure the systems. The software specs were to enable following software engineers to compile the software. They usually did have a few diagrams, which sometimes I updated for the good of my soul, but nobody ever read them. Generally I used the comms protocol documents to write the softwware.
Now I hear UML and object oriented design is all the thing, and Yourdons methodology and similar methodologies are consigned to the scrapheap. I've read about UML but I haven't used it. If it actually helps, then that's ok. If all it does is duplicate work and create inconsitency then I'm not sure it's a good thing. If a design tool actually:
- generated some code, such as the function prototypes
- reflected any changes made to the code back into the design
- did not force any unnecessary duplication, such as pseudo-code and actual code
- automatically generated documentation needed to satisfy the ISO9000 inspector
then I think it would be worthwhile. Otherwise I don't.
