How important is architecture to C developers?
 

I'm a C++ developer and I am always sure to distinguish this from a C
developer any time there seems to be confusion. As a software
developer I can adapt to any language and API, and so I can adapt to
using C when I need to, but even though the two languages share much
in common I rarely use those aspects of C++ that are C.

I was recently hired into a new position. I knew there would be some
C development but I was lead to believe that this would be *legacy*
development and that I was being hired as a C++ developer. Turns out
that this was not at all the case and now I'm rather stuck.
Unfortunately I'm having a lot of trouble adapting to the situation
and I'm not sure if this is because I lack understanding of the C
"way", as I have not used it in 10 years, or if I'm just in a
generally troubling situation as it seems to me.

The lead architect of the project I'm on does not seem to have any
room for different ways of doing things. Unfortunately, he doesn't
seem to have a lot of eye toward architecture to begin with and so
when I come in and try to impose some we get into disagreements. For
example, we have a structure in the program that's got about 100 items
in it. It's kept in an array in global scope. Any function that uses
this structure takes an index to that array even if it doesn't do
anything but retrieve or manipulate a value within one instance of
that structure. I tried to factor this out so I could write some
functions that behaved differently and didn't depend on this global
array and I was in an argument for an hour attempting to justify this
action, apparently with little success.

From where I come from, I wouldn't expect to HAVE to justify such a
change. The function doesn't need or care about the array, so why
make it? Reduce dependencies, open the function for reuse, and
increase cohesion even if by a small amount. That I can make the
change easily, and I'm already messing with things in the area, means
I should do it.

There are also a lot of functions that seem to do a lot of things and
because everything seems to be a global variable, they end up touching
everything. This forces everyone that needs to work on the code into
the position of having to understand the entire thing in detail,
rather than some small area they are working on. It is a truism that
this happens to code, but this is early in the project's lifecycle and
the architect that created it doesn't seem to like me splitting
concerns, encapsulating data, etc... I'm trying to write C++ in C?

Again though, I made sure to make sure they knew that I was a C++
developer, not C. I can work with C when I need to interface with it,
but that's about it.

One thing that seems to guide this person is a desire to avoid heap
memory. For example, we have a somewhat predictable in size but
constantly changing string the we have to construct. I proposed that
we consider a buffer that grows with each call so that we pay minimal
cost in performance but yet never have to predict or worry about the
size of this string again. He agreed we should discuss it but was
busy so I took a day and implemented it. Had it under unit tests,
valgrind, etc...it worked. I find though that he has no room for this
construct and would prefer to use a statically sized character array
and error out if we hit the end for some reason. I suppose this could
be a philosophical difference perhaps with the C way vs. the C++ way
but I honestly do not understand the problem.

I do understand the fear of malloc. I hate memory leaks and without
RAII or a very clear ownership semantic it's very difficult, perhaps
impossible to avoid them. I do understand the argument that heap is
less predictable than the stack or global space in that malloc can
fail or fragment memory. On the other hand, we're targeting a very
powerful server with lots of memory and a buffer that grows as it
needs to and just sits around waiting is not likely to cause a lot of
fragmentation, which occurs more often when you repeatedly allocate
and deallocate objects.

Encapsulation of data seems to be a hard sell too. I wish to hide the
fact that this object is using a buffer, and in fact implemented the
buffer with a structure I don't want anyone other than itself to mess
with either. Yes, this is sort of object oriented, except for the
total lack of polymorphism and inheritence, but it seems to me like
just a good idea. If you want to keep code from mucking about in data
it shouldn't, encapsulate it. When I've tried to do this though I've
had to spend a lot of time trying to justify it as well because I'm
"complicating things". Unfortunately I see it as exactly the opposite
because I find strongly cohesive, encapsulated entities much easier to
work on than a conglomerate of functions that operate on a mishmash of
global variables.

We have totally different approaches to things. Mine is to face
change by trying to find a method to adapt the design of the program
to be compatible with the change and then extending it. His method
seems to be to hack at it until it seems to work. He is pretty smart
and so generally it appears he is successful, but I've never been a
big fan of this approach to software maintenance. I find it too
risky, prone to failing in bad ways that cost lots of money, and
shortens the lifetime of projects by making them fragile to
modification and difficult to learn.

On the one hand I feel like I'm stuck under someone that has no
understanding of software design, a total apathy toward architecture
and good technique, and no toleration for different methods. On the
other hand, he's got decades of experience on me and is apparently
quite able to develop successful products. What I can't decide is how
much of this is due to being able to convince people he knows what
he's doing, and only working on small code bases.

The goal I have here is to find out if this is simply the C way that I
need to learn, and thus I should just STFU and be instructed, or are
the techniques I tend to use as universal as I perceive them to be and
my concerns are valid...meaning I still need to STFU and let things be
what they are but I might also be looking for ways out of the
situation.

Re: How important is architecture to C developers?
 

On Sat, 1 Oct 2011 14:49:48 -0700 (PDT), nroberts
<roberts.noah@gmail.com> wrote:

>I'm a C++ developer and I am always sure to distinguish this from a C
>developer any time there seems to be confusion. As a software
>developer I can adapt to any language and API, and so I can adapt to
>using C when I need to, but even though the two languages share much
>in common I rarely use those aspects of C++ that are C.
>
>I was recently hired into a new position. I knew there would be some
>C development but I was lead to believe that this would be *legacy*
>development and that I was being hired as a C++ developer. Turns out
>that this was not at all the case and now I'm rather stuck.
>Unfortunately I'm having a lot of trouble adapting to the situation
>and I'm not sure if this is because I lack understanding of the C
>"way", as I have not used it in 10 years, or if I'm just in a
>generally troubling situation as it seems to me.
>
>The lead architect of the project

[snippety snip]

Hosted or stand-alone? New C *tends* to show up more in non-hosted
environments, i.e. embedded processors, where how things are done are
strongly influenced by the environmental constraints. Is there anything
special about the project?

--
Rich Webb Norfolk, VA

Re: How important is architecture to C developers?
 

On Oct 1, 3:14*pm, Rich Webb <bbew...@mapson.nozirev.ten> wrote:
> On Sat, 1 Oct 2011 14:49:48 -0700 (PDT), nroberts
>
>
>
>
>
>
>
>
>
> <roberts.n...@gmail.com> wrote:
> >I'm a C++ developer and I am always sure to distinguish this from a C
> >developer any time there seems to be confusion. *As a software
> >developer I can adapt to any language and API, and so I can adapt to
> >using C when I need to, but even though the two languages share much
> >in common I rarely use those aspects of C++ that are C.
>
> >I was recently hired into a new position. *I knew there would be some
> >C development but I was lead to believe that this would be *legacy*
> >development and that I was being hired as a C++ developer. *Turns out
> >that this was not at all the case and now I'm rather stuck.
> >Unfortunately I'm having a lot of trouble adapting to the situation
> >and I'm not sure if this is because I lack understanding of the C
> >"way", as I have not used it in 10 years, or if I'm just in a
> >generally troubling situation as it seems to me.
>
> >The lead architect of the project
>
> [snippety snip]
>
> Hosted or stand-alone? New C *tends* to show up more in non-hosted
> environments, i.e. embedded processors, where how things are done are
> strongly influenced by the environmental constraints. Is there anything
> special about the project?
>

Hosted. It's got to be fast and up all the time is all that's special
about it.

Re: How important is architecture to C developers?
 

On 10/01/2011 05:49 PM, nroberts wrote:
> I'm a C++ developer and I am always sure to distinguish this from a C
> developer any time there seems to be confusion. As a software
> developer I can adapt to any language and API, and so I can adapt to
> using C when I need to, but even though the two languages share much
> in common I rarely use those aspects of C++ that are C.

Most of the aspects of C++ are C; it's pretty hard, probably impossible,
to use C++ without using the aspects it shares with C, such as using '+'
as the addition operator, or terminating expression statements with
semi-colons. I think you mean something more complicated than what you
actually said.

> I was recently hired into a new position. I knew there would be some
> C development but I was lead to believe that this would be *legacy*
> development and that I was being hired as a C++ developer. Turns out
> that this was not at all the case and now I'm rather stuck.
> Unfortunately I'm having a lot of trouble adapting to the situation
> and I'm not sure if this is because I lack understanding of the C
> "way", as I have not used it in 10 years, or if I'm just in a
> generally troubling situation as it seems to me.
>
> The lead architect of the project I'm on does not seem to have any
> room for different ways of doing things. Unfortunately, he doesn't
> seem to have a lot of eye toward architecture to begin with and so
> when I come in and try to impose some we get into disagreements. For
> example, we have a structure in the program that's got about 100 items
> in it. It's kept in an array in global scope. Any function that uses
> this structure takes an index to that array even if it doesn't do
> anything but retrieve or manipulate a value within one instance of
> that structure. I tried to factor this out so I could write some
> functions that behaved differently and didn't depend on this global
> array and I was in an argument for an hour attempting to justify this
> action, apparently with little success.
>
> From where I come from, I wouldn't expect to HAVE to justify such a
> change. The function doesn't need or care about the array, so why
> make it? Reduce dependencies, open the function for reuse, and
> increase cohesion even if by a small amount. That I can make the
> change easily, and I'm already messing with things in the area, means
> I should do it.
>
> There are also a lot of functions that seem to do a lot of things and
> because everything seems to be a global variable, they end up touching
> everything. This forces everyone that needs to work on the code into
> the position of having to understand the entire thing in detail,
> rather than some small area they are working on. It is a truism that
> this happens to code, but this is early in the project's lifecycle and
> the architect that created it doesn't seem to like me splitting
> concerns, encapsulating data, etc... I'm trying to write C++ in C?

Most of what you're talking about is bad design in C, as well as C++. C
has fewer tools for encapsulation than C++ does, but good C designers
use those tools where appropriate. Bad designers (in either language)
come up with messes like the ones you describe.

> One thing that seems to guide this person is a desire to avoid heap
> memory. ...

Whether or not that's a legitimate concern depends upon the environment.
In my current environment, it isn't, but I've worked in ones where it
was. Do you know for certain that his concern about heap usage is
excessive, given the target platforms for this software?

....
> valgrind, etc...it worked. I find though that he has no room for this
> construct and would prefer to use a statically sized character array
> and error out if we hit the end for some reason. I suppose this could
> be a philosophical difference perhaps with the C way vs. the C++ way
> but I honestly do not understand the problem. ...

If it's a legitimate problem on that platform, there's a good chance
that it's a legitimate concern in both languages - it isn't C-specific.

> On the one hand I feel like I'm stuck under someone that has no
> understanding of software design, a total apathy toward architecture
> and good technique, and no toleration for different methods.

I've reached a point in my career where no one cares to exert authority
over me on issues of how my programs are designed; I've got complete
freedom to use whichever architecture I think is best. That's because
I'm clearly far more competent to decide such issues than my bosses are;
they're more competent than me on management skills (mine are awful).
But I didn't reach that point till I was 40 (someone whose career
involved fewer side-tracks than mine might have gotten there earlier).
Until you get there, you'll have to learn to deal with bosses whose
judgment differs from yours, and may even be inferior to yours.

> The goal I have here is to find out if this is simply the C way that I
> need to learn, and thus I should just STFU and be instructed, or are
> the techniques I tend to use as universal as I perceive them to be and
> my concerns are valid...meaning I still need to STFU and let things be
> what they are but I might also be looking for ways out of the
> situation.

Nothing you've described is C specific.
--
James Kuyper

Re: How important is architecture to C developers?
 

"nroberts" <roberts.noah@gmail.com> wrote in message
news:138d547d-36d2-44f2-b1c5-4cca241c71f2@c1g2000yql.googlegroups.com...

> For example, we have a somewhat predictable in size but
> constantly changing string the we have to construct. I proposed that
> we consider a buffer that grows with each call so that we pay minimal
> cost in performance but yet never have to predict or worry about the
> size of this string again. He agreed we should discuss it but was
> busy so I took a day and implemented it. Had it under unit tests,
> valgrind, etc...it worked. I find though that he has no room for this
> construct and would prefer to use a statically sized character array
> and error out if we hit the end for some reason.

But if you had a dynamically changing string, would you impose any upper
bound on the size?

If not, then some temporary glitch in the size would probably cause the
machine to run out of memory and to bring everything down.

And if there is a limit, then it's little different from the static
solution!

So possibly both kinds of approaches to this project have their points; and
who has ultimate responsibility for the software working reliably?

(I've mostly worked by myself but remember having a supervisor who didn't
quite see the point of these new-fangled 'subroutines' I was sprinkling
through my code! Then he saw how easy some mods became, and started seeing
the point.

Maybe you need to find a similar example to help 'sell' your approach, but
that'll be much harder in your case, with an existing project.)

--
Bartc

Re: How important is architecture to C developers?
 

On 10/ 2/11 10:49 AM, nroberts wrote:
> I'm a C++ developer and I am always sure to distinguish this from a C
> developer any time there seems to be confusion. As a software
> developer I can adapt to any language and API, and so I can adapt to
> using C when I need to, but even though the two languages share much
> in common I rarely use those aspects of C++ that are C.
>
> I was recently hired into a new position. I knew there would be some
> C development but I was lead to believe that this would be *legacy*
> development and that I was being hired as a C++ developer. Turns out
> that this was not at all the case and now I'm rather stuck.
> Unfortunately I'm having a lot of trouble adapting to the situation
> and I'm not sure if this is because I lack understanding of the C
> "way", as I have not used it in 10 years, or if I'm just in a
> generally troubling situation as it seems to me.

I think the best advise is to brush up your CV and start digging a
tunnel. Being a round peg in a square hole invariably leads to tears.

> The lead architect of the project I'm on does not seem to have any
> room for different ways of doing things. Unfortunately, he doesn't
> seem to have a lot of eye toward architecture to begin with and so
> when I come in and try to impose some we get into disagreements. For
> example, we have a structure in the program that's got about 100 items
> in it. It's kept in an array in global scope. Any function that uses
> this structure takes an index to that array even if it doesn't do
> anything but retrieve or manipulate a value within one instance of
> that structure. I tried to factor this out so I could write some
> functions that behaved differently and didn't depend on this global
> array and I was in an argument for an hour attempting to justify this
> action, apparently with little success.

As other responders have noted, this is bad design, regardless of
language. C lacking the higher level features of C++ is no excuse for a
bad design.

<snip>

> The goal I have here is to find out if this is simply the C way that I
> need to learn, and thus I should just STFU and be instructed, or are
> the techniques I tend to use as universal as I perceive them to be and
> my concerns are valid...meaning I still need to STFU and let things be
> what they are but I might also be looking for ways out of the
> situation.

What you are experiencing is a personality clash, not a language culture
one.

--
Ian Collins

Re: How important is architecture to C developers?
 

On 01-Oct-11 16:49, nroberts wrote:
> I'm a C++ developer and I am always sure to distinguish this from a C
> developer any time there seems to be confusion. As a software
> developer I can adapt to any language and API, and so I can adapt to
> using C when I need to, but even though the two languages share much
> in common I rarely use those aspects of C++ that are C.

C++ isn't that different from C. C++ has some nifty syntactic sugar
that make doing many things the "right way" a bit easier, but good
design is the same in _any_ language, particularly two as closely
related as C and C++.

> The lead architect of the project I'm on does not seem to have any
> room for different ways of doing things.

Regardless of the specifics, this is a bad sign. A good architect will
always be open to new ideas and, if they're better than his, will adopt
them. A closed mind is a big problem in any language--indeed, in any field.

> For example, we have a structure in the program that's got about 100
> items in it.

I've seen a handful of cases where that's appropriate, but they're
pretty rare.

> It's kept in an array in global scope.

There are many folks against having _any_ global variables; I tend to
avoid such absolutism, but they probably got that way from dealing with
projects like yours...

> On the one hand I feel like I'm stuck under someone that has no
> understanding of software design, a total apathy toward architecture
> and good technique, and no toleration for different methods. On the
> other hand, he's got decades of experience on me and is apparently
> quite able to develop successful products. What I can't decide is how
> much of this is due to being able to convince people he knows what
> he's doing, and only working on small code bases.

I suspect his "success" is due to being able to maintain absolute
control over projects small enough (and with few enough developers) that
he can keep the entire thing in his head at the same time.

> The goal I have here is to find out if this is simply the C way that I
> need to learn, and thus I should just STFU and be instructed, or are
> the techniques I tend to use as universal as I perceive them to be and
> my concerns are valid...meaning I still need to STFU and let things be
> what they are but I might also be looking for ways out of the
> situation.

Your concerns appear to be valid. The problem is not the language,
though, as what you want to do is IMHO the "right" way to do things in C
as well as C++. Only the syntax differs.

It sounds like a "way out of the situation" is probably your best
option, but in the meantime you'd probably best be served by adapting to
your environment. Just, for the sake of your career, don't stick around
any longer than necessary, lest you internalize some of his poor design
(and management/teamwork) practices and take them with you when you leave.

S

--
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking

Re: How important is architecture to C developers?
 

On 10/1/2011 4:55 PM, Ian Collins wrote:
> On 10/ 2/11 10:49 AM, nroberts wrote:
>> I'm a C++ developer and I am always sure to distinguish this from a C
>> developer any time there seems to be confusion. As a software
>> developer I can adapt to any language and API, and so I can adapt to
>> using C when I need to, but even though the two languages share much
>> in common I rarely use those aspects of C++ that are C.
>>
>> I was recently hired into a new position. I knew there would be some
>> C development but I was lead to believe that this would be *legacy*
>> development and that I was being hired as a C++ developer. Turns out
>> that this was not at all the case and now I'm rather stuck.
>> Unfortunately I'm having a lot of trouble adapting to the situation
>> and I'm not sure if this is because I lack understanding of the C
>> "way", as I have not used it in 10 years, or if I'm just in a
>> generally troubling situation as it seems to me.
>
> I think the best advise is to brush up your CV and start digging a
> tunnel. Being a round peg in a square hole invariably leads to tears.
>
>> The lead architect of the project I'm on does not seem to have any
>> room for different ways of doing things. Unfortunately, he doesn't
>> seem to have a lot of eye toward architecture to begin with and so
>> when I come in and try to impose some we get into disagreements. For
>> example, we have a structure in the program that's got about 100 items
>> in it. It's kept in an array in global scope. Any function that uses
>> this structure takes an index to that array even if it doesn't do
>> anything but retrieve or manipulate a value within one instance of
>> that structure. I tried to factor this out so I could write some
>> functions that behaved differently and didn't depend on this global
>> array and I was in an argument for an hour attempting to justify this
>> action, apparently with little success.
>
> As other responders have noted, this is bad design, regardless of
> language. C lacking the higher level features of C++ is no excuse for a
> bad design.
>

yep.


global variables and arrays are ugly IMO, and better off avoided (I
personally prefer to avoid global variables wherever possible, and
generally create and pass around "context structs" which contain most data).

FWIW, I typically use contexts (in C) similarly to how many people use
classes in OO languages, but with the obvious difference that there is
no built-in support for inheritance (most commonly, cases which would
normally be done via inheritance are handled instead by having pointers
to the data for the "sub-classes", and by making use either of explicit
vtables or function pointers).


also, by convention, I tend to manually use explicit constructors and
destructors (via function calls to create and destroy objects) rather
than have client code allocate/free the memory directly.

also, fairly often an analogue of getters/setters is used.

scope issues are generally avoided through explicit naming conventions
(name clashes are not some unavoidable fault of the language, rather
they are more often an issue with poor naming conventions or ones'
failure to adhere to them).


> <snip>
>
>> The goal I have here is to find out if this is simply the C way that I
>> need to learn, and thus I should just STFU and be instructed, or are
>> the techniques I tend to use as universal as I perceive them to be and
>> my concerns are valid...meaning I still need to STFU and let things be
>> what they are but I might also be looking for ways out of the
>> situation.
>
> What you are experiencing is a personality clash, not a language culture
> one.
>

yeah...

C and C++ need not really be all that much different.

mostly it is a difference of language syntax.


many arguments IME are more often about philosophical views and coding
practices than about real technical matters.

for example, recent arguments about coding practices because, for
example, I don't believe copy-paste is necessarily a bad thing, and that
there may be worse issues at play (making copy/paste a lesser of the
evils). not that it is always a good thing either (if one is just
endlessly copy-pasting a sequence of code which could just as easily
have been put in a function, yes, this is a bad thing...).

another recent argument was partly because I tend to believe that
computers (and reality as a whole) are made out of "stuff" (software,
hardware, matter, ...) rather than being made out of math or similar
(for whatever bizarre reason, some people seem to believe everything is
made out of math...). I instead tend to see math as a system of
abstractions and formalisms, which exist largely independently from the
things they describe. (like "existence precedes essence" and similar).

so, yes, there are potential conflicts everywhere...



in the cases where I write C++, admittedly it often looks a little more
C like (I rarely make much use of STL/Boost/...), and often it tends to
be reasonably conservative (C++ features used sparingly) as often the
border back to C land is not too far away.


granted, there is apparently a faction off in C++ land who often writes
code which looks like it escaped from Java or something.

typically a big tree of C++ files, each containing a single class, and
typically all #include'ed by a big root C++ file:
#include "foo/A.cpp"
#include "foo/B.cpp"
#include "foo/C.cpp"
#include "bar/A.cpp"
....

sometimes, one sees #import here instead.

however, I don't suspect this is the "standard" practice (I haven't seen
all that many projects which do this, although single-class-per-file
does seem to be fairly common in many projects).

I generally go instead by the convention of liking around 500-1000 lines
per file (too much smaller means excess jumping between files, and too
much larger makes scrolling/navigation tedious).


or such...

Re: How important is architecture to C developers?
 

On Oct 1, 2:49*pm, nroberts <roberts.n...@gmail.com> wrote:
> I'm a C++ developer and I am always sure to distinguish this from a C
> developer any time there seems to be confusion. *As a software
> developer I can adapt to any language and API, and so I can adapt to
> using C when I need to, but even though the two languages share much
> in common I rarely use those aspects of C++ that are C.
>
> I was recently hired into a new position. *I knew there would be some
> C development but I was lead to believe that this would be *legacy*
> development and that I was being hired as a C++ developer. *Turns out
> that this was not at all the case and now I'm rather stuck.
> Unfortunately I'm having a lot of trouble adapting to the situation
> and I'm not sure if this is because I lack understanding of the C
> "way", as I have not used it in 10 years, or if I'm just in a
> generally troubling situation as it seems to me.
>
> The lead architect of the project I'm on does not seem to have any
> room for different ways of doing things. *Unfortunately, he doesn't
> seem to have a lot of eye toward architecture to begin with and so
> when I come in and try to impose some we get into disagreements. *For
> example, we have a structure in the program that's got about 100 items
> in it. *It's kept in an array in global scope. *Any function that uses
> this structure takes an index to that array even if it doesn't do
> anything but retrieve or manipulate a value within one instance of
> that structure. *I tried to factor this out so I could write some
> functions that behaved differently and didn't depend on this global
> array and I was in an argument for an hour attempting to justify this
> action, apparently with little success.
>
> From where I come from, I wouldn't expect to HAVE to justify such a
> change. *The function doesn't need or care about the array, so why
> make it? *Reduce dependencies, open the function for reuse, and
> increase cohesion even if by a small amount. *That I can make the
> change easily, and I'm already messing with things in the area, means
> I should do it.
>
> There are also a lot of functions that seem to do a lot of things and
> because everything seems to be a global variable, they end up touching
> everything. *This forces everyone that needs to work on the code into
> the position of having to understand the entire thing in detail,
> rather than some small area they are working on. *It is a truism that
> this happens to code, but this is early in the project's lifecycle and
> the architect that created it doesn't seem to like me splitting
> concerns, encapsulating data, etc... *I'm trying to write C++ in C?
>
> Again though, I made sure to make sure they knew that I was a C++
> developer, not C. *I can work with C when I need to interface with it,
> but that's about it.
>
> One thing that seems to guide this person is a desire to avoid heap
> memory. *For example, we have a somewhat predictable in size but
> constantly changing string the we have to construct. *I proposed that
> we consider a buffer that grows with each call so that we pay minimal
> cost in performance but yet never have to predict or worry about the
> size of this string again. *He agreed we should discuss it but was
> busy so I took a day and implemented it. *Had it under unit tests,
> valgrind, etc...it worked. *I find though that he has no room for this
> construct and would prefer to use a statically sized character array
> and error out if we hit the end for some reason. *I suppose this could
> be a philosophical difference perhaps with the C way vs. the C++ way
> but I honestly do not understand the problem.
>
> I do understand the fear of malloc. *I hate memory leaks and without
> RAII or a very clear ownership semantic it's very difficult, perhaps
> impossible to avoid them. *I do understand the argument that heap is
> less predictable than the stack or global space in that malloc can
> fail or fragment memory. *On the other hand, we're targeting a very
> powerful server with lots of memory and a buffer that grows as it
> needs to and just sits around waiting is not likely to cause a lot of
> fragmentation, which occurs more often when you repeatedly allocate
> and deallocate objects.
>
> Encapsulation of data seems to be a hard sell too. *I wish to hide the
> fact that this object is using a buffer, and in fact implemented the
> buffer with a structure I don't want anyone other than itself to mess
> with either. *Yes, this is sort of object oriented, except for the
> total lack of polymorphism and inheritence, but it seems to me like
> just a good idea. *If you want to keep code from mucking about in data
> it shouldn't, encapsulate it. *When I've tried to do this though I've
> had to spend a lot of time trying to justify it as well because I'm
> "complicating things". *Unfortunately I see it as exactly the opposite
> because I find strongly cohesive, encapsulated entities much easier to
> work on than a conglomerate of functions that operate on a mishmash of
> global variables.
>
> We have totally different approaches to things. *Mine is to face
> change by trying to find a method to adapt the design of the program
> to be compatible with the change and then extending it. *His method
> seems to be to hack at it until it seems to work. *He is pretty smart
> and so generally it appears he is successful, but I've never been a
> big fan of this approach to software maintenance. *I find it too
> risky, prone to failing in bad ways that cost lots of money, and
> shortens the lifetime of projects by making them fragile to
> modification and difficult to learn.
>
> On the one hand I feel like I'm stuck under someone that has no
> understanding of software design, a total apathy toward architecture
> and good technique, and no toleration for different methods. *On the
> other hand, he's got decades of experience on me and is apparently
> quite able to develop successful products. *What I can't decide is how
> much of this is due to being able to convince people he knows what
> he's doing, and only working on small code bases.
>
> The goal I have here is to find out if this is simply the C way that I
> need to learn, and thus I should just STFU and be instructed, or are
> the techniques I tend to use as universal as I perceive them to be and
> my concerns are valid...meaning I still need to STFU and let things be
> what they are but I might also be looking for ways out of the
> situation.

Or the situation might be looking to get you out of it...

For many if not most jobs, what you describe about yourself is
the classic description of a bad employee. You are given a job to
do, and a set of existing tools and policies and procedures to
complete
the job, but instead of doing the job you proceed to complain
about the tools and policies and procedures, and even take it
upon yourself WITHOUT AUTHORIZATION to create your own policies
and procedures, BUT I HAVEN'T HEARD ONE WORD FROM YOU ABOUT
ACTUALLY DOING THE JOB YOU WERE HIRED TO DO.

Of course, this type of behavior is not atypical in programming,
but that still doesn't make it acceptable. I remember one time,
a FORMER programmer in another group, who was quite mystified
as to why he couldn't find work, regaled the group with a story
about how he unilaterally decided the debugger that he was
provided with wasn't good enough, so he set upon a year-long
task to write his own. I did try to inform him that if he
was working for me, assigning yourself an open-ended task of
writing a debugger rather than doing the job you were hired
to do would be your last act as an employee, and if I found
out in the hiring process you were prone to that type of
behavior, I would not hire you.

Fortunately for you and him, I don't work as an engineering
manager, and based on my experience with a lot of engineering
managers, that may be because I'm over-qualified, at least
in the common sense department, if not tediously technically
well-versed...

So, in any event, that's just MY opinion, but it's also
my opinion that possibly what you describe IS bad "architecture",
because it generally doesn't sound too good, but then I also
don't know enough about software requirements and development
history to make a canonical determination...what you describe may
also be a REASONABLE solution to the requirements over time, and at
least one other respondant to this thread has noted that on one issue
you may not be thinking 100% clearly...

Would it be so difficult to give your BOSS the benefit of
the doubt, and try to be a "team player"? Especially considering
doing otherwise might get VERY difficult for you...

---
William Ernest Reid

Re: How important is architecture to C developers?
 

On Oct 2, 5:48*pm, Bill Reid <hormelf...@gmail.com> wrote:
> On Oct 1, 2:49*pm, nroberts <roberts.n...@gmail.com> wrote:

> For many if not most jobs, what you describe about yourself is
> the classic description of a bad employee. *You are given a job to
> do, and a set of existing tools and policies and procedures to
> complete
> the job,

Actually...

Also, perhaps you think otherwise but "team player" to me does not
mean yes man.