SQL Clone
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


Picking Your Packaging


Picking Your Packaging

Author
Message
Andy Warren
Andy Warren
SSChampion
SSChampion (14K reputation)SSChampion (14K reputation)SSChampion (14K reputation)SSChampion (14K reputation)SSChampion (14K reputation)SSChampion (14K reputation)SSChampion (14K reputation)SSChampion (14K reputation)

Group: Moderators
Points: 14993 Visits: 2730
Comments posted to this topic are about the item Picking Your Packaging

Andy
SQLAndy - My Blog!
Connect with me on LinkedIn
Follow me on Twitter
Gary Varga
Gary Varga
SSCoach
SSCoach (19K reputation)SSCoach (19K reputation)SSCoach (19K reputation)SSCoach (19K reputation)SSCoach (19K reputation)SSCoach (19K reputation)SSCoach (19K reputation)SSCoach (19K reputation)

Group: General Forum Members
Points: 19763 Visits: 6534
Long term maintainability is the key. Given that the original coder is often unavailable (left or busy) it is essential that any piece of code is as easy to pick up as is possible. How this ease is managed is down to each individual scenario, however, there are many ways to make this impossible such as relying on tools which are not archived so may be no longer available, tools requiring unobtainable hardware or software (like a dongle or license).

Also undocumented solutions.

I am not talking about reams of documentation but a few choice comments somewhere providing a bit of a heads up to what is going on helps.

Gaz

-- Stop your grinnin' and drop your linen...they're everywhere!!!
MKEDataGuy
MKEDataGuy
Old Hand
Old Hand (350 reputation)Old Hand (350 reputation)Old Hand (350 reputation)Old Hand (350 reputation)Old Hand (350 reputation)Old Hand (350 reputation)Old Hand (350 reputation)Old Hand (350 reputation)

Group: General Forum Members
Points: 350 Visits: 108
Yes, maintainability is key. But, the technology used is only part of the choice. The actual design of the solution is probably more important. If it is designed well, and documented as needed, then it should be easy to understand.

I'm often reminded of Code Complete by Steve McConnell... The one thing that most stood out to me from this book was that a particular tool or technology may or may not natively support good coding practices, but a good developer (or DBA) knows how to implement good coding practices anyway and will find ways to work within the chosen technology. For example, T-SQL does not natively support the ideal of constants, but that does not mean I can't use variables in my T-SQL as constants to improve readability and maintainability.

This is why I say that the design, and good coding practice, are more important than a particular technology.

Thanks,
MKE Data Guy
eric.notheisen
eric.notheisen
Old Hand
Old Hand (315 reputation)Old Hand (315 reputation)Old Hand (315 reputation)Old Hand (315 reputation)Old Hand (315 reputation)Old Hand (315 reputation)Old Hand (315 reputation)Old Hand (315 reputation)

Group: General Forum Members
Points: 315 Visits: 296
I believe there are several considerations to be made relative to this issue. First and foremost are you working for yourself or for the company that pays you? If you own the company you can make the decision based on any consideration you choose. If you are working for someone else than the decision should be based on what is best for the company. In my experience, the best decision for the company is the option that is most effective at the least cost. This falls under the heading of fiduciary responsibility and duty to your employer. That being said, future maintenance consideration must be built into the decision as well.

I once worked on a project in 2007 where the architect and technical lead wanted to develop the application using the latest technology. In this case the technology was in beta and had not been release as a production ready platform. His idea was to load all controls on a web page dynamically at runtime. The application worked one year after the planned release date and is still difficult to maintain by less than expert developers because of the technology used. In my opinion this was a bad decision all around.

Although I very much appreciate getting into the latest and greatest technology, my responsibility to the company that pays me forces me to consider maintenance and security over anything else.
OCTom
OCTom
Hall of Fame
Hall of Fame (3.5K reputation)Hall of Fame (3.5K reputation)Hall of Fame (3.5K reputation)Hall of Fame (3.5K reputation)Hall of Fame (3.5K reputation)Hall of Fame (3.5K reputation)Hall of Fame (3.5K reputation)Hall of Fame (3.5K reputation)

Group: General Forum Members
Points: 3475 Visits: 4152
I agree that it's important to consider who may work on the code in the future. If we're talking DBA's, then what can one assume that a future DBA will know? Is it safe to assume he/she will know C#/VB.Net? Do we put the package together for a beginning DBA or one with 5 yrs, 10 yrs experience? Do we write it so the least competent DBA will be able to work on it?

I doubt it's a good idea to try some whiz-bang new technique just because you want to learn it. I like to take the middle of the road. I try to learn new techniques when they come out, but won't put them into production code until a couple of years down the road. That way, competent people will have the ability to work with it. I'm assuming a certain level of competence, of course. I will have to trust that my employer will hire someone at least as good as I am. ;-)

Tom
Jim P.
Jim P.
Ten Centuries
Ten Centuries (1.1K reputation)Ten Centuries (1.1K reputation)Ten Centuries (1.1K reputation)Ten Centuries (1.1K reputation)Ten Centuries (1.1K reputation)Ten Centuries (1.1K reputation)Ten Centuries (1.1K reputation)Ten Centuries (1.1K reputation)

Group: General Forum Members
Points: 1147 Visits: 2215
OCTom (1/17/2014)
I agree that it's important to consider who may work on the code in the future. If we're talking DBA's, then what can one assume that a future DBA will know? Is it safe to assume he/she will know C#/VB.Net? Do we put the package together for a beginning DBA or one with 5 yrs, 10 yrs experience? Do we write it so the least competent DBA will be able to work on it?

In my view, I would shy away from any compiled solution unless the company has a source control system that is expected to be around for a while.

My last company transitioned into developing with VB.Net from using Access FE's. A developer came in after one left and had to try and make a change. They had no source control other than raw files on disk. His efforts took weeks.



----------------
Jim P.

A little bit of this and a little byte of that can cause bloatware.
call.copse
call.copse
SSCarpal Tunnel
SSCarpal Tunnel (4.4K reputation)SSCarpal Tunnel (4.4K reputation)SSCarpal Tunnel (4.4K reputation)SSCarpal Tunnel (4.4K reputation)SSCarpal Tunnel (4.4K reputation)SSCarpal Tunnel (4.4K reputation)SSCarpal Tunnel (4.4K reputation)SSCarpal Tunnel (4.4K reputation)

Group: General Forum Members
Points: 4368 Visits: 1952
I think it sensible to consider how well 'signposted' the solution is. As our company is a .Net based development company we have a reasonable expectation that to find a particular codebase we would look down a particular route. Just convention I guess.

Then you have how easy it is to link what you are seeing with what is in a code file. The more levels of remove you have the less signposted the location is and the harder to trace. I guess that is similar to the point on packaging?
KGERBR
KGERBR
SSC-Enthusiastic
SSC-Enthusiastic (126 reputation)SSC-Enthusiastic (126 reputation)SSC-Enthusiastic (126 reputation)SSC-Enthusiastic (126 reputation)SSC-Enthusiastic (126 reputation)SSC-Enthusiastic (126 reputation)SSC-Enthusiastic (126 reputation)SSC-Enthusiastic (126 reputation)

Group: General Forum Members
Points: 126 Visits: 224
I like the idea, yet it seems like I’m losing in one area to win in another. There is real value in trying out new/different technologies, both as a person and as an individual.



You're forgetting one thing ... its not always about you.
Peter E. Kierstead
Peter E. Kierstead
Mr or Mrs. 500
Mr or Mrs. 500 (522 reputation)Mr or Mrs. 500 (522 reputation)Mr or Mrs. 500 (522 reputation)Mr or Mrs. 500 (522 reputation)Mr or Mrs. 500 (522 reputation)Mr or Mrs. 500 (522 reputation)Mr or Mrs. 500 (522 reputation)Mr or Mrs. 500 (522 reputation)

Group: General Forum Members
Points: 522 Visits: 453
So many competing issues; and there always will be.
As the amount data increases and the depth of historical context deepens I find the shops I work in to be moving towards the following hierarchy:

  • Code for performance - this means proven best of bread components and distributed processing

  • Code for maintainability - point one is more complex and requires a clear and concise architecture not only for its authors but for future contributors

  • Code for configurability - its easier for an operator to change options than for a programmer to change code (and subsequent testing; and yes, these options have to be planned and coded)


Some may add to this list, however, most shops won't have the bandwidth to do much more.
I think acceptable compromises can be reached and effective, maintainable solutions implemented.



PeteK
I have CDO. It's like OCD but all the letters are in alphabetical order... as they should be.
John Hanrahan
John Hanrahan
SSC Eights!
SSC Eights! (925 reputation)SSC Eights! (925 reputation)SSC Eights! (925 reputation)SSC Eights! (925 reputation)SSC Eights! (925 reputation)SSC Eights! (925 reputation)SSC Eights! (925 reputation)SSC Eights! (925 reputation)

Group: General Forum Members
Points: 925 Visits: 1466
The first consideration is your company not you. That said if it's a one off project then I'd say there is some latitude otherwise it I would think maintainability is a VERY big consideration.
Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search