B
Branimir Maksimovic
Andrew McDonagh said:
And how you are supposed to run tested features without framework?
Greetings, Bane.
most software jobs are software maintenance rather than new development?
And how you are supposed to run tested features without framework?
Greetings, Bane.
P
pauldepstein
Chris said:
Well, the OP gives the strong impression of having inappropriately high
expectations of what to expect from employment, given the OP's
admittedly limited knowledge.
I was offended by this, and I was not the only one. I'm a bit
surprised that this reaction -- being offended -- was not the universal
one.
I posted a parody of the OP in another thread. It expresses my
opinions of the OP very well and I'm quite proud of the parody:
My parody is printed verbatim below as part of my posting excerpt:
Some explanation is needed. The reason the OP is off-topic (in some
newsgroups) is that the thread was included in newsgroups on the _c++
language_.
EXCERPT BEGINS BELOW
I also find it absurdly ironic that, in marked contrast to the attitude
towards compiler/platform discussions, the following posting, which was
_wildly irrelevant_, induced a long and sober thread of replies, and
did not seem to be condemned as OT by anybody.
Yesterday's irrelevant (but apparently not judged OT) thread began as
follows:
" I would like to share my distress at the way I have been treated in
my new entry-level job as a java programmer. (I have 3 months
programming experience). My salary is less than 2 million dollars a
year, and my boss has never offered to provide me with a chauffeur to
drive me into work, even though I live in a neighboring town.
Furthermore, last week he treated me to dinner at a Chinese restaurant,
and I was shocked and appalled to notice a small stain on one of the
tablecloths.
Are such experiences typical of everyone, or am I just unlucky?"
END OF EXCERPT
Paul Epstein
B
Branimir Maksimovic
I call this technique: a "chaotic development style"
Normal consequence is that dozens of small incopatible frameworks and
redundant
code emerge from each team and then when integration comes to play
they spend lot of wasted time to refactor the code for nothing.
Greetings, Bane.
Normal consequence is that dozens of small incopatible frameworks and
redundant
code emerge from each team and then when integration comes to play
they spend lot of wasted time to refactor the code for nothing.
Greetings, Bane.
R
Robert C. Martin
Smalltalk vs. Cobol? That's a no-brainer. XP vs. Waterfall? That's
also a no-brainer. Working with Kent? No-brainer.
-----
Robert C. Martin (Uncle Bob) | email: (e-mail address removed)
Object Mentor Inc. | blog: www.butunclebob.com
The Agile Transition Experts | web: www.objectmentor.com
800-338-6716
"The aim of science is not to open the door to infinite wisdom,
but to set a limit to infinite error."
-- Bertolt Brecht, Life of Galileo
A
Andrew McDonagh
Branimir said:
By Framework - I took you to mean that you created some Generic
infrastructure for your application, that is also specific the type of
application you are developing - as in JBoss, JavaMail, Etc...
If I'm wrong - can you explain a bit what you do mean by Framework.
If I'm right - Then any application can be developed without generic
Frameworks within it - they still run.
If the customer needs an app that reads stock market info and sends them
an email when ever their own stocks value starts to drop, then we don't
need any framework for this.
If the customer then wants us to add in the ability to send them an SMS
text msg instead of an email - we MAY decide that we need a generic
Messaging Transport framework of some kind or we may NOT - there is only
two message transports to be used - the 'framework' at this point is an
'IF' statement or polymorphic call at best.
If the customer added a third message transport type (web page updates,
Carrier Pigeons, Motorcycle Dispatches etc) then it is usually prudent
to use a framework.
But right in the beginning - it just sent emails - so we didn't need a
generic Messaging Framework.
Is that a good enough example?
please don't mis-understand me - I'm not anti-framework, I'm just
against prematurely-introducing-frameworks. I've seen to many projects
be months late because the team thought they needed to have a framework
in place BEFORE they could do anything, rather than INTRODUCE a
framework later when they really do have a need.
Andrew
A
Andrew McDonagh
Branimir Maksimovic wrote:
Snipped.
Thats ok - I call it by its real name: Agile development.
Are you talking about Frameworks for multiple teams or about multiple
developers on a single team each separately developing a 'framework'
then merging into main line for the rest of the team to use?
Snipped.
Thats ok - I call it by its real name: Agile development.
Are you talking about Frameworks for multiple teams or about multiple
developers on a single team each separately developing a 'framework'
then merging into main line for the rest of the team to use?
R
Ross Bamford
Finally, argue against the solutions you're provided, while selecting the
best one and implementing it anyway, claiming you 'Found the answer
elsewhere'.
A
Andrew McDonagh
Andrew said:
oh WRT 'anti-framework' here's a very funny post on Joel-on-software...
http://discuss.joelonsoftware.com/default.asp?joel.3.219431.39
"....Actually, we don't sell hammers at all.
So...
According to our research, what people really needed wasn't a Universal
Hammer after all. It's always better to have the right kind of hammer
for the job. So, we started selling hammer factories, c...."
B
Branimir Maksimovic
Andrew McDonagh said:
Necessary work to be done in order to provide module integration
and testing, also there belongs skeleton code implementing
different design patterns. A library if you want.
What I can say. You can work in any way you like.
This type of development is not good for larger programs.
For small ones no problem you can change on the fly, but....
adding features always depends on how flexible the design is.
Oh, they didn't know how to do it. First, scatch design, then make framework
interface, then develop features , then integrate and test in framework.
OO is designed to simplify things. You don't need finished
framework in order to write usefull code.
Framework should be written only *once* and later just adapted
for other projects.
It goes pretty fast. Even you can do this: one team can write framework
other
payload code.
Greetings, Bane.
R
Roedy Green
There are many cues missing you get with verbal communication that
lead to foul-ups in newsgroup communication.
You don't have the voice print/accent/dialect cue on every word to
remind you who is saying what.
You don't get the body language or cues of emotion, joking, anger...
With voice, you can tell immediately if someone is disagreeing or
seconding or augmenting. In newsgroups that is not obvious and leads
to all kinds of puzzlement when the wrong assumption is applied.
Everybody talks at once about everything.
The speaker does not get immediate feedback by quizzical looks when he
is not being understood.
It is easy to mistake the age, sex, or intelligence of a newsgroup
poster. This is particularly true when you add in people whose first
language is not English.
In face to face communication WHO said something is very important. It
is easy to lose track in newsgroups.
On the other paw, you can always get a word in edgewise no matter how
long winded someone else is, and nobody can shout you down.
Then there is the matter of stage fright. People who would never say
boo in public will fearlessly tackle anyone in a newsgroup even in
front of hundreds of readers.
B
Branimir Maksimovic
Both. In reality both cases can happen when applying chaotic development
style.
Gretings, Bane.
B
Branimir Maksimovic
Andrew McDonagh said:
Good one !
A
Andrew McDonagh
Branimir said:
Oh yes Design Patterns - another favorite. With many issues as
Frameworks. I do actually love patterns - think they are great - so
much so that I mentor people in them.
I also show them that they are useful when needed - but not before.
Now, 'when needed' might be straight away - or might be a years time.
Our experience is different - what can I say.
Well they all had very experienced people on them going about it very
much as you describe - though how long was spent on each of those stages
was different per team. Different as in some scratched the design,
others spent a long time fine tuning, and others somewhere in the middle.
They were still late because everyone of them had frameworks that were
over engineered for the actual purpose of the the current feature sets.
producing code/frameworks/libraries for future use or because things
changed that meant they weren't used as much as expected - is waste in
the Lean Six Sigma sense.
Simplify over what?
I have - with mixed results.
On teams where there was poor inter-team communication and common goals,
it failed miserably every time we integrated.
On teams where there was great inter-team communication and both teams
shared common goals (as in my current work place) it works great.
Like I said - I'm not against frameworks.
B
Branimir Maksimovic
Andrew McDonagh said:
I don't understand this? There exists programs that don't use not even
single
design pattern? I didn't mean the Design Patterns. Well yes design patterns
are the Design Patterns, sometimes not.
One always know what patterns would be needed in current project
and add them to library as necessary. I didn't said that framework has
to be swiss knife or some kind of perfection. This is impossible.
You are actually describing well known anti pattern.
So I see. They just over complicated things.
That is another matter. Framework shouldn't be over complicated.
In the begining it can just provide small interface not much of a code
but yet usefull and evolve in time.
One designs framework by current need with extensions in mind.
I don't understand. It is designed to make code maintenance more flexible.
Therefore abstract interfaces and all that stuff. This is simply THE tool
and invitation for writing frameworks. I've started with procedural
languages untill I found OO. Now I need less much time to achieve
tasks then before.
Problem is now that many people overcomplicate things, more
then necessary
Greetings, Bane.
P
puzzlecracker
Branimir said:Good one !
This thread becomes uncontrolled, off-topic, off-subject, and full of
subjective opinions that no one in their rational mind can give weight
to.
In short, most of above is a plain exercise in futility. After all,
this is a C++ group and not who-can-bull-shit-more group!
enough SAID, for I am doing and perpetuating above with deterrent
intentions.
B
Branimir Maksimovic
puzzlecracker said:
Hm, there exists such thing as objective opinion? If there is a
such thing that would be sum of all subjective opinions divided by
number of opinions.
Well, there is comp.lang.c++.moderated, but then again this topic
was started as crosspost so original message could be
successfull troll.
Greetings, Bane.
P
Phlip
Robert said:
Greenfield vs legacy? Imagine if all else was equal...
Now instead imagine the decision between an average legacy project
(test-free), and a legacy project built via clean and expressive unit tests.
No brainer.
D
Daniel Parker
You mean like C3 today? Just kidding. But the choice that you'd like toPhlip said:
see isn't usually the choice confronting a new entrant into the programming
world. Maintenance programmers typically work on a branch off the main line
and their job is to fix production bugs and address the needs of the day.
The main development line is usually happening elsewhere.
I agree with the call to extend automated acceptance test coverage. Many IT
shops are way behind there, and could benefit from that enormously.
-- Daniel
D
Daniel Parker
It's the technical lead who needs to know the answer to that question. BackBranimir Maksimovic said:
when I ran small teams that had to do things, staffed with young programmers
who didn't know how to do them, I would give something to someone and the
important thing was that they made progress, not that they necessarily
finished the task. If they took it to 80 percent, perhaps with some
guidence, someone more senior could step in and finish it off. Leads have
to know their resources and what they can do. It's an extremely valuable
skill to learn how to accomplish something when you don't know how to do it,
it's a good thing to be in an environment where you can experience that. At
one time all companies had to do a lot of things internally, and everbody
had to learn. Now they don't have to do as much, they get used to buying
things, and many seem to have forgotten completely how to build anything.
-- Daniel
T
Thad Smith
(e-mail address removed) wrote:
[Regarding discussions of a post inquiring whether it is normal
for a new programmer to only do maintenance]
If you aren't pulling our leg, I think you are being too easily offended.
The OP struck me as naive with respect to programming careers, not
pompous. If you are taught to write new programs, you naturally expect
to get a programming job writing new programs! I think the better
description of his circumstance was probably surprise and some
frustration. Perhaps it is time to revamp the education of those
heading into programming to better prepare them for maintenance.
Thad
[Regarding discussions of a post inquiring whether it is normal
for a new programmer to only do maintenance]
If you aren't pulling our leg, I think you are being too easily offended.
The OP struck me as naive with respect to programming careers, not
pompous. If you are taught to write new programs, you naturally expect
to get a programming job writing new programs! I think the better
description of his circumstance was probably surprise and some
frustration. Perhaps it is time to revamp the education of those
heading into programming to better prepare them for maintenance.
Thad