4 ms·
I'd have a minor quibble with that -- as someone who's done both application/product development and "dev ops": there's a difference when you write software tha
by strlen 17y ago
I'd have a minor quibble with that -- as someone who's done both application/product development and "dev ops": there's a difference when you write software that you yourself are the end-user of and when you write software for others to use/operate. That was the biggest challenge (initially) for me when I transitioned to "software engineering".
I've found that for infrastructure projects (especially open source ones, which may not always have dedicated QA resources available to them) it's a great idea to do "adversarial" testing/documentation: someone other than the developer must be able to follow the documentation and use the software in an environment other than the developer's desktop.
- jpd 17y agoTrue, but just because it starts as a personal project doesn't mean it has to stay that way. For example, z/OS's TERSE (a compression utility) was once someone's personal project, but is now shipped with the operating system. I'm sure there are many such examples. That said, these personal projects are no longer treated as such, and have gone through Test, and et cetera before being included in the system release.
- strlen 17y agoThat's true. Brooks mentions this as the "program-system" and/or "program-product"/"system-system product" boundaries (I may have the terms confused, I don't have the book in front of me). There's probably a range of software development: 0. "Script" (not necessarily something written in a scripting language, merely a short program written in an ad-hoc manner). 1. Program (could well be in a scripting language) 2. Project 3. Possibly a system (composed of multiple programs and/or projects) 4. Product 6. Company