Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase 123»»»

Picking Your Packaging Expand / Collapse
Author
Message
Posted Friday, January 17, 2014 12:07 AM
SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: Moderators
Last Login: Yesterday @ 2:30 PM
Points: 6,784, Visits: 1,899
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
Post #1531938
Posted Friday, January 17, 2014 2:32 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Today @ 4:41 PM
Points: 5,471, Visits: 3,258
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!!!
Post #1531965
Posted Friday, January 17, 2014 6:29 AM
Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Wednesday, September 10, 2014 5:48 AM
Points: 318, Visits: 107
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
Post #1532024
Posted Friday, January 17, 2014 6:39 AM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Thursday, September 25, 2014 6:32 AM
Points: 41, Visits: 42
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.
Post #1532028
Posted Friday, January 17, 2014 7:19 AM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Today @ 12:53 PM
Points: 2,581, Visits: 3,883
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
Post #1532049
Posted Friday, January 17, 2014 7:58 AM


SSChasing Mays

SSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing Mays

Group: General Forum Members
Last Login: Tuesday, September 23, 2014 7:42 PM
Points: 635, Visits: 2,215
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.
Post #1532069
Posted Friday, January 17, 2014 8:15 AM


SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Today @ 6:36 AM
Points: 1,712, Visits: 1,129
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?
Post #1532080
Posted Friday, January 17, 2014 8:16 AM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Friday, September 26, 2014 9:56 AM
Points: 66, Visits: 118
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.

Post #1532082
Posted Friday, January 17, 2014 8:47 AM


SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Friday, June 20, 2014 2:22 PM
Points: 190, Visits: 436
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.
Post #1532098
Posted Friday, January 17, 2014 9:36 AM
SSC-Addicted

SSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-Addicted

Group: General Forum Members
Last Login: Today @ 2:28 PM
Points: 407, Visits: 1,025
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.
Post #1532139
« Prev Topic | Next Topic »

Add to briefcase 123»»»

Permissions Expand / Collapse