2

For the company I work at, all of our projects,
including a new one started last year, are written in C89.
We write for vxWorks (a real time embedded operation system).
Our software runs multi-threaded through various spawned "tasks"

We are massively behind schedule, and I am struggling to be productive based on the company's design for new software components.

Coming from a C++ background, I'm use to wrapping mutable state inside of a class, and then providing methods as an interface to manipulate the state:

enter image description here

I realize that C doesn't have these language features, but I've always been under the impression that C developers do something similar with a set of global functions and having their "struct" as the first argument to all of these functions.

enter image description here

In both of these cases, we still have an interface. It describes the actions that can be taken on the component, and helps with readability / dealing with mutable state.

enter image description here


I am not allowed to write software components in the way I described above.

Our company design, as I have come to understand it, is as followed:

  • Every component must be expressed as a TypeInput, and a TypeOutput.
  • Each component will have two global functions associated with it:
    • Initialize (takes and modifies TypeOutput)
    • Update (takes TypeInput, and TypeOutput; modifies TypeOutput)

Here is the smallest example I could find that helps express the idea.
A popable breaker:

typedef struct CircuitBreakerInputs_t
{
    BOOL m_bPopped;

} CircuitBreakerInputsT;

typedef struct CircuitBreakerOutputs_t
{
    BOOL m_bPopped;

} CircuitBreakerOutputsT;

void InitializeCircuitBreaker(CircuitBreakerOutputsT *const ptOutputs)
{
  //initalizes ptOutputs
}

void UpdateCircuitBreaker(CircuitBreakerOutputsT *const ptOutputs, const CircuitBreakerInputsT *const ptInputs)
{
   //observes inputs to modify outputs
}

On the surface, this may seem like a simple and straightforward design.
Inputs become outputs based on the current state of outputs.


Now consider a component with more than one functionality. Let's take a millisecond timer. It can move forward in time, be paused, be unpaused, and be reset. That would look like this:

typedef struct MillisecondTimerInputs_t
{
    BOOL m_bAdvanceTime;

    BOOL m_bSetPauseState;

    BOOL m_bReset;

    BOOL m_bPause;

} MillisecondTimerInputsT;

typedef struct MillisecondTimerOutputs_t
{
    double m_dElapsedTime_ms;

    BOOL m_bPaused;

    unsigned long m_ulLastUpdateTickAmount;

} MillisecondTimerOutputsT;

void InitializeMillisecondTimer(MillisecondTimerOutputsT *const ptOutputs){
      //initializes ptOutputs
}
void UpdateMillisecondTimer(MillisecondTimerOutputsT *const ptOutputs, const MillisecondTimerInputsT *const ptInputs){
       //observes inputs to modify outputs
}

This gets more complicated to use. Our inputs, are becoming triggers as to how we want to use the component. In order to get the specified functionality out of our component, we need to move the interface into the Update call and rely on the input data to dispatch appropriately.

enter image description here

Of course, this allows you to call more than one hidden method when setting more than one method trigger(a boolean) to true. If the order in which the methods are called matters, you are left to either rely on the implementation, or set each one to triggers separately and call Update for each of them.

You also need to be careful that you aren't calling any additional methods by accident. For example, when you construct the InputType, you need to set all the triggers to false initially. Then you need to set the trigger you want to call to true, and call update. You then need to potentially set that trigger back to false if you intend on enabling a new trigger for the next update.

To make the process easier, I began using enums to represent the method I want to call. This was more in accordance with the initial design I showed earlier, because only one method can be called based on the enumerated value.

enter image description here

I had to revert back to the booleans through because our design did not permit a third enumerated type for doing this kind of dispatch.

The only way I was able to write concise tests for these components, was by creating a set of utility functions that take the OutputType, forward params into the input struct, and surface the appropriate output as a return value. This gave me back the interface I lost.

enter image description here

I then went on to write a language that allowed me to express code in the same manner as the first diagram. I write code as a stateful object with an API in C++, and it can algorithmically be turned into any of the other diagrams shown thus far. Based on this design I can better construct, and test the code. I generate the input/output C design, and then I generate a C++ wrapper that holds the C OutputType, and provides the interface shown in the diagram above.


My automation breaks down in regards to component composition.
Our company prohibits InputTypes from containing OutputTypes, and vice versa. Which is unfortunate, because the OutputTypes are what have the state. So I can't easily pass a component into the method of another component. It is inputs, outputs, and updates all the way down. Additionally, you can only call update once for each of the sub components.

enter image description here

Only being able to call Update once on each of the sub-components, has also hurt my productivity. Dealing with component interaction, and component transformation has to be done over the duration of various Updates. There are other routes I have tried to take, but it overcomplicates the Input/Output types.

Are there good merits to this design?
The lead engineer has told me:

however the stateful object above has no specific division of memory for mutual exclusion. In order to do this, we needed new objects for memory management and cross thread locks

Is this design better for multithreading? I don't understand why we couldn't just make copies, and still use the threading mechanisms appropriate when dealing with shared memory. Additionally, we don't use any threading in our sub components, and the highest level OutputType, gets copied while performing a semaphore locked read/write. We also don't use any dynamic memory allocation on the heap, but even if we did, I don't think this would affect the explanation. We would just need to manage that memory appropriately, when making copies and such.

  • 2
    I don't see anything that immediately jumps out as bad about the design. What I do see is that you are trying to change a culture (your dev team) that is not only resisting, but actively telling you no. This question sounds like you want our approval on a design/implementation that you can then take to your team to say "See? I am right!" Or am I missing the actual purpose of this question... – Adam Zuckerman May 1 '16 at 6:37
  • 1
    @AdamZuckerman We failed our last two projects, are now being sued, and are already overdue on our current project that is only 20% done. Yes, I think my design is better, but after being told "no", I am trying to fit in, and understand our design decisions. I was hoping others could shed light on the positives of this design, because I have not received any clear answers back from my team. From my perspective we are hammering in screws. I don't want to be confrontational, I just want to understand the merits of the design. I want to do my job well-- that's it. – Trevor Hickey May 1 '16 at 7:03
  • 6
    You might want to start handing out your resume. Based on what you have told me, this is a place that you should run away from as fast as possible. But that is another topic for a different location. – Adam Zuckerman May 1 '16 at 7:07
  • 1
    Changing the design of software isn't likely to do very much to change your delivery timescales. If anything, changing a design of an already late project is extremely likely to make it even later - especially where part of your proposal is to introduce some new and unfamiliar tools and practices to the development team. Failings of a late project are nearly always down to the way the project is managed (Chances are the project was already doomed before even a single line of code had been written), and as such, can only be solved through better project management. – Ben Cottrell May 1 '16 at 11:27
  • 2
    Finally, this development team will always be able to supply you with reasons for their design decisions. They might even be good reasons. But none of that matters if they can't deliver working software in a reasonable time frame. – Robert Harvey May 1 '16 at 21:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.