OT: Development Cycle

  • Thread starter Thread starter Terry
  • Start date Start date
T

Terry

I'm not sure where to take this request, but I know this to be a reliable
forum so please forgive me this off topic post.

I've applied for a job as a junior system developer but the job spec may
just be out of reach. A few questions answered might help:

I'm an access man, so:

I'm reasonably adept at VBA, is it a big jump from this to VB?

I'm reasonably adept at SQL, is it a big jump to sqlserver?

Where can i find a good breakdown of the, perhaps generic, 'development
cycle' and its methodologies?

Any help would be most gratefully received.

Thanks in advance.

Terry
 
Find out what the customer says he wants.

Find out what he REALLY wants.

Find out what he actually NEEDS

Write a specification in consultation with the customer to address the needs

Break the needs down into maneagable chunks

Develop each chunk

Fit the lot back together into a working project

Deliver

Add development to cover omissions/extensions in the initial specification.

Fix the bugs

Not terribly on topic, but it might be a start.

--
Regards,

Adrian Jansen
J & K MicroSystems
Microcomputer solutions for industrial control
 
I'm not sure where to take this request, but I know this to be a reliable
forum so please forgive me this off topic post.
I've applied for a job as a junior system developer but the job spec may
just be out of reach. A few questions answered might help:

A junior developer is not expected to be Albert Einsten, or to have
memorized the MSDN, or to know every programming language ever invented!
Don't assume that you can't do it. Assume that you >can< do it.

I'm an access man, so:

I'm reasonably adept at VBA, is it a big jump from this to VB?

VB has a different object model to Access. But the basic ideas of forms,
controls etc. are similar. If you have got to level 'x' of understanding in
Access, you can doubtless get to the same level in VB. But understand that
they >are< different, so you can not transfer Access knowledge >verbatim< to
VB in all/any/most/some cases.

I'm reasonably adept at SQL, is it a big jump to sqlserver?

You're comparing apples to oranges. SQL is a language. SQL Server is a
database product. With a product like SQL server, you would have application
programmers who understood how to write forms & reports using that product;
and you might also have "database administrators" who knew how to install
the product, perform backups, crash recoveries, & so on. Those are fairly
different knowledge sets. You could be skilled at one, but not very skilled
at the other. You'll want to get these differences clear, before you try
discussing them with your prospective new employer! personally, I would not
feel comfortable with someone who equated SQL to SQL Server ... ;-)

Where can i find a good breakdown of the, perhaps generic, 'development
cycle' and its methodologies?

Here's my bet: typing "software development life cycle" into google will
produce fifty thousand squintillion hits ...

HTH,
TC
 
I'm not sure where to take this request, but I know this to be a
reliable
A junior developer is not expected to be Albert Einsten, or to have
memorized the MSDN, or to know every programming language ever invented!
Don't assume that you can't do it. Assume that you >can< do it.

I will take that assumption into the interview if I'm shortlisted.
VB has a different object model to Access. But the basic ideas of forms,
controls etc. are similar. If you have got to level 'x' of understanding in
Access, you can doubtless get to the same level in VB. But understand that
they >are< different, so you can not transfer Access knowledge >verbatim< to
VB in all/any/most/some cases.

Access/VBA has the data source integrated, which i would guess simplifies
the process quite a lot. I'll find a basic to intermediate VB introduction
course to pick up some database connectivity terms, esp. with relation to
sqlserver.
You're comparing apples to oranges. SQL is a language. SQL Server is a
database product. With a product like SQL server, you would have application
programmers who understood how to write forms & reports using that product;
and you might also have "database administrators" who knew how to install
the product, perform backups, crash recoveries, & so on. Those are fairly
different knowledge sets. You could be skilled at one, but not very skilled
at the other. You'll want to get these differences clear, before you try
discussing them with your prospective new employer! personally, I would not
feel comfortable with someone who equated SQL to SQL Server ... ;-)

I appreciate that. My question was a little loose to say the least! Access
makes a lot of coding so easy by providing an SQL View of a Query, which I
generally cut and paste into vba code and take it from there. I'm sure this
doesn't provide for advanced SQL, but it makes many tricky problems a doddle
to overcome.

i guess what i really want to know is this: Is SQLServer as user-friendly as
Access and, given that i have a good understanding of SQL and MS products,
will I be able to find my way around the application intuitively? If that's
still unclear, then perhaps I should just assume I can :)
Here's my bet: typing "software development life cycle" into google will
produce fifty thousand squintillion hits ...

about a million and a half, which is enough to be getting on with.!

Thanks a lot for your time, TC.

Terry
 
Find out what the customer says he wants.
Find out what he REALLY wants.

Find out what he actually NEEDS

Write a specification in consultation with the customer to address the needs

Break the needs down into maneagable chunks

Develop each chunk

Fit the lot back together into a working project

Deliver

Add development to cover omissions/extensions in the initial specification.

Fix the bugs

Not terribly on topic, but it might be a start.

That's a good 'bread and butter' overview and pretty much how I've managed
Access projects over the past five years. However, I couldn't have put it
better and if I'm put into a position where I have to be succinct I'll draw
heavily from it.

Thanks Adrian

Terry
 
Is SQLServer as user-friendly as
Access and, given that i have a good understanding of SQL and MS products,
will I be able to find my way around the application intuitively? If that's
still unclear, then perhaps I should just assume I can :)

No, it's not. It's considerably more complex - T-SQL, stored
procedures, and the like, and much less of a GUI interface.

But it's doable. If you've got the knack of thinking relationally
you're 80% up the learning curve; the rest is just study and work.
 
Applies to every engineering project I have tackled over the last 30 years
or so. But I never thought of writing it down in quite so brief a form
until the OP query.

--
Regards,

Adrian Jansen
J & K MicroSystems
Microcomputer solutions for industrial control
 
(snip)
i guess what i really want to know is this: Is SQLServer as user-friendly as
Access and, given that i have a good understanding of SQL and MS products,
will I be able to find my way around the application intuitively? If that's
still unclear, then perhaps I should just assume I can :)

I've not used SQL Server myself. However, it is basically just another
enterprise-level DBMS (database management system) - and I have used other
such products, eg. Oracle.

In most such products, you have an underlying database management product
(the DBMS), and a set of associated development tools for writing programs,
forms & reports etc. for use with that product.

DBMS Development tools

Access MS Jet MS Access

SQL Server SQL Server ?

I don't know what the development tools are called in SQL server. Your
question really is, are those tools as eay to use as MS Access. I don't know
the answer to that, so someone else might jump in here (or you could post
that as a new question).

However, be aware that the complexity of the DBMS part, will definitely be
greater than the complexity of MS Jet. For example, all enterprise-level
DBMS's have special features for taking live backups, or restoring the data
after file corruption. MS Jet has no such features. Enterprise-level DBMS's
have so-called "ACID transactions". MS Jet has no such feature, & so on.

So there is a learning curve for the DBMS part of SQL Server, over & above
the learning curve its development tools (whatever those are). A "database
administrator" would be expert in the DBMS part, and hopefully have a
reasonable understanding of the development tools. Conversely, a "database
programmer" or developer, would be competent in the development tools, but
would not necessarily know much about the underlying DBMS.

Hope this helps. Good luck with the job!

TC
 
Is SQLServer as user-friendly as
No, it's not. It's considerably more complex - T-SQL, stored
procedures, and the like, and much less of a GUI interface.

But it's doable. If you've got the knack of thinking relationally
you're 80% up the learning curve; the rest is just study and work.

I'm all for learning so I'll hunt out some tutorials and will also see if i
can get my hands on the app itself.

Thanks John.

Terry
 
So there is a learning curve for the DBMS part of SQL Server, over & above
the learning curve its development tools (whatever those are). A "database
administrator" would be expert in the DBMS part, and hopefully have a
reasonable understanding of the development tools. Conversely, a "database
programmer" or developer, would be competent in the development tools, but
would not necessarily know much about the underlying DBMS.

Hope this helps. Good luck with the job!

TC

Hmmm, that lot gives me something to get my teeth into. I've enjoyed working
with Access as a sole developer as it allows me to get my hands on on all
aspects of the build, which is hard work, but great fun too. I've never
really thought about specialising before, but perhaps now is the time to
park the white van and join the big boys!!

Thanks again for all your input, i'll make good use of it.

Terry
 
Applies to every engineering project I have tackled over the last 30 years
or so. But I never thought of writing it down in quite so brief a form
until the OP query.

--
Regards,

Adrian Jansen
J & K MicroSystems
Microcomputer solutions for industrial control

Yeah, I suspect it's not quite the development cycle they will expect to
hear during the interview, but it works well as an informal brief :)

Cheers
Terry
 
Back
Top