Developing frameworks: Requirements?

  • Thread starter Thread starter Brett
  • Start date Start date
B

Brett

Are developers that are involved in creating frameworks for categories of
business' and as industry standards usually some of the highest quality
developers writing software? If not, who has such a status?

Also, what requirements might a framework developer have? In other words,
how did some one reach such a position?

Thanks,
Brett
 
Well brett, Its the experience that developers have and of the architect who
designs the framework. I believe that there are no such boundaries defined
for either framework developers or winform developers or any kind of
developer as long as the developer has the knowledge and the skills to apply
whatever the architect designs he/she can be a framework developer. But as i
am saying all this is its is really difficult to gain a wide variety of
skills like knowledge about OS Behaviour, Perf, Integration, Scalability,
etc,etc, that these developers have and when you reach that position you
yourself will feel that i really accomplished something and now i need to do
something more than i am currently doing.

-Umer.
 
Brett <[email protected]> said:
Are developers that are involved in creating frameworks for categories of
business' and as industry standards usually some of the highest quality
developers writing software? If not, who has such a status?

Also, what requirements might a framework developer have? In other words,
how did some one reach such a position?

Not the same level you are talking about, but in my last job I was
responsible for, and designed and wrote much of, the company's software
architecture. This worked through having a cross-project responsibility
to act as a consultant to ensure that other people didn't reinvent the
wheel, and to analyse which problems could be solved in a more general
way such that we could both reuse the work for other projects and also
ensure consistency for maintainability. I started off at that company as
a junior software developer and worked my way up. I think I did a pretty
good job of it, though there are things I would do better if I did it
again; it was the first time I'd designed a framework, and I learnt a
lot of lessons the hard way.

I would say that the important things are having the confidence and
respect of your colleagues in your technical skill, the communication
skills to explain your ideas and a full knowledge of the problem domain;
bear in mind that your problem domain is not just supporting the
requirements of the business, but also supporting the requirements of
the developers. By this, I mean that you need to know not only what the
systems delivered on the back of your framework will be required to do,
but also how they will be implemented.

It's fun, though.
 
Steve Walker said:
Not the same level you are talking about, but in my last job I was
responsible for, and designed and wrote much of, the company's software
architecture. This worked through having a cross-project responsibility to
act as a consultant to ensure that other people didn't reinvent the wheel,
and to analyse which problems could be solved in a more general way such
that we could both reuse the work for other projects and also ensure
consistency for maintainability. I started off at that company as a junior
software developer and worked my way up. I think I did a pretty good job
of it, though there are things I would do better if I did it again; it was
the first time I'd designed a framework, and I learnt a lot of lessons the
hard way.

I would say that the important things are having the confidence and
respect of your colleagues in your technical skill, the communication
skills to explain your ideas and a full knowledge of the problem domain;
bear in mind that your problem domain is not just supporting the
requirements of the business, but also supporting the requirements of the
developers. By this, I mean that you need to know not only what the
systems delivered on the back of your framework will be required to do,
but also how they will be implemented.

It's fun, though.

I like your view of this. Thanks. What was your official title?

You didn't get any formal training for the position? At what point did the
company decide you were ready for this position?

Brett
 
[QUOTE="Brett said:
I would say that the important things are having the confidence and
respect of your colleagues in your technical skill, the communication
skills to explain your ideas and a full knowledge of the problem domain;
bear in mind that your problem domain is not just supporting the
requirements of the business, but also supporting the requirements of the
developers. By this, I mean that you need to know not only what the
systems delivered on the back of your framework will be required to do,
but also how they will be implemented.

It's fun, though.
[/QUOTE]
I like your view of this. Thanks. What was your official title?

Consultant (Software Architecture)

We had another guy who was at the same level and responsible for the
database architecture.
You didn't get any formal training for the position?

Not specifically. My background is science, and so my instinct is to
seek out the literature. Our training budget was always overstretched,
but there was usually money for books.
At what point did the
company decide you were ready for this position?

*Laugh*

The promotion from Senior Developer was a recognition of what I was
already doing rather than a change in it. I started as a junior
developer doing VBA/Access development, moved on to VB6 thick client
apps and then ASP/MTS distributed apps. The latter was a new technology
for our company, and I did the research to find out how to build them. I
also wrote an authentication system for the intranet using VB6 to mimic
the NT challenge/response mechanism; we couldn't at that time use
windows authentication, so I wrote an activeX control to query and hash
a secure attribute in the Novell directory system and an MTS component
to verify it against a database. So I was gradually moving towards
having a hand in the common application infrastructure and being the
team expert on how the technology worked.

I got a number of technology/methodology research projects, one of which
was an evaluation of the beta .NET release. By this point we'd taken to
heart the Gospel according to Deborah Kurata, and were about as OO as
you could be with VB6. The limitations of the language were starting to
drive me nuts, so the prospect of real OO in VB.NET was very exciting.

As part of my research I taught myself C#, and instantly fell in love
with it. I recommended that we adopt .NET immediately it was released,
and that we take the C# route rather than the VB.NET route. After some
initial dissent from other developers, this was accepted. I'd also
taught myself UML, and recommended that we adopt UML/UP. We sent all of
the developers on a five day C# course, and the whole department on a
UML course.

So, I guess how I got the position was by making myself the team guru on
the technologies we were using, and by being a strong advocate of the
need to get reuse from components by factoring out architectural
functionality from application specific functionality. I wrote a lot of
the framework code because it was easier to do it myself than to get
someone else to do it.
 
Back
Top