January 17, 2014 at 12:07 am
Comments posted to this topic are about the item Picking Your Packaging
January 17, 2014 at 2:32 am
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!!!
January 17, 2014 at 6:29 am
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
January 17, 2014 at 6:39 am
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.
January 17, 2014 at 7:19 am
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
January 17, 2014 at 7:58 am
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.
January 17, 2014 at 8:15 am
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?
January 17, 2014 at 8:16 am
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.
January 17, 2014 at 8:47 am
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:
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.
January 17, 2014 at 9:36 am
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.
January 17, 2014 at 10:35 am
..Imagine that you’re contemplating a project that will involve running multiple SQL statements and maybe some PowerShell against a list of instances, and then storing the results for later analysis. Based on that very short set of requirements, which tool would you think of using to solve the problem? ..
..I have a friend who argues that the most important consideration is how approachable the solution will be for the next DBA – the one that years from now will have to fix something that is suddenly failing. That DBA is going to appreciate the solution with the least amount of packaging – the noise he has to filter through to get down to the code..
One solution would be Central Management Server, which would integrate with SSMS server groups, a tool the DBA is already familiar with. In addition to deployments or routine maintenance scripts, that would also allow the DBA to execute a one-off T-SQL statement, like a DMV query or DBCC command, across multiple server and get the result back in a single resultset.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
January 17, 2014 at 11:44 am
I have a multi-threaded .Net service that provides those capabilities to support our 4,500 store locations. Most requests complete in less than 3 minutes. Fully web driven and results can be viewed or downloaded.
January 17, 2014 at 12:11 pm
EricEyster (1/17/2014)
I have a multi-threaded .Net service that provides those capabilities to support our 4,500 store locations. Most requests complete in less than 3 minutes. Fully web driven and results can be viewed or downloaded.
But can the guy that comes behind you find the source code so that when the managers want a report by groups of states instead of individual ones so he can modify it?
----------------
Jim P.
A little bit of this and a little byte of that can cause bloatware.
January 17, 2014 at 12:17 pm
Jim P. (1/17/2014)
EricEyster (1/17/2014)
I have a multi-threaded .Net service that provides those capabilities to support our 4,500 store locations. Most requests complete in less than 3 minutes. Fully web driven and results can be viewed or downloaded.But can the guy that comes behind you find the source code so that when the managers want a report by groups of states instead of individual ones so he can modify it?
Yes, they could modify the base code, but that is not how my service works. Users create the select statement and then they select servers (comma delimited) or by selecting from the organizational structure (all east coast, etc). we have used the service for years to perform daily system checks on all stores and have not had to touch the code, just enter new SQL statements.
January 17, 2014 at 1:18 pm
Here's my vote for a tool I just learned to use this year: SQL Packager from Redgate. Cuts out all the need for hand coding, can also include DIFF packages for both schema and data (works with SQL Compare and SQL Data Compare to generate). Hands down the best database deployment solution I've ever seen.
Ted Seeber
I find your secrets in your data.
http://www.informaitonr.us
Viewing 15 posts - 1 through 15 (of 22 total)
You must be logged in to reply to this topic. Login to reply