Working Up

by Dwayne Phillips Systems engineering consumes resources. It isn’t “real engineering.” It, however, is usually necessary. Systems engineering—one part of it—enables us to record what everything is and what everything does. But we already know that, duh! Or do we? Consider an organization with three or 33 software systems. What does #1 do? #2?…#33? How […]

[Read more →]

by Dwayne Phillips The recent rash of misuse and abuse of social media reminds us of that old, boring practice called systems engineering and limiting systems to do only what they are supposed to do. Recent news reports point to all sorts of “misuse” and “abuse” of social media platforms like Facebook and Twitter. These […]

[Read more →]

by Dwayne Phillips A review of one of the fundamentals of systems engineering. We create and manage budgets of key technical performance measures. System engineers work with technical budgets. Examples: size weight power attenuation memory use RAM memory use disk time to complete an operation We are building a smartphone. We are told to keep […]

[Read more →]

by Dwayne Phillips Agile development is not an excuse for knowing what you did, why you did it, and how you did it. You’re doing agile development. You hold a meeting to start a sprint (different methods use different names for this). You sprint! You meet again at the end of the sprint. What did […]

[Read more →]

by Dwayne Phillips Take great care when everyone agrees about something. Once the world was plagued with the longitude problem. Long-distance sea travel was dangerous and fraught with the great unknown, “where are we?!?!?!?” Everyone agreed on the solution to the longitude problem. Everyone, that is, except the carpenter who solved the problem. For background, […]

[Read more →]

by Dwayne Phillips One function of systems engineering is to open the black boxes, look at the entire system, and apply some wisdom. We often build systems by connecting existing systems and subsystems. These existing pieces are black boxes, i.e., we don’t know or don’t care to know what is inside them and how they […]

[Read more →]

by Dwayne Phillips Systems are commonly built by connecting smaller systems. This requires that the systems are connect-able, and that requires a defined interface. Most of the time, we build systems by connecting large boxes together in a system diagram. There are exceptions, and another post will discuss some of those. Still, connect the boxes […]

[Read more →]

by Dwayne Phillips Working software is more valuable than documentation—except when it isn’t. And we have Dwayne’s Declaration. Part of the Agile Manifesto states: We…value working software over comprehensive documentation Some of us are old enough to have known this years before the manifesto was manifest. Of course we wanted working software, except when we […]

[Read more →]

by Dwayne Phillips There are major differences between engineering systems and “just doing it.” The consequences are both obvious and predicted. For at least 25 years, I have heard and seen in action the mantra of “good enough software.” Get a partial solution, ship it, improve it. Great stuff. Except time has shown that the […]

[Read more →]

by Dwayne Phillips Being a computer programmer does not make me a software engineer. Deep sigh before I begin. This is yet another post borne of frustration in talking with recruiters and hiring managers. Now that the sigh is out of the way. A computer programmer is not a software engineer. There. Wrote that bit. […]

[Read more →]