November 15, 2016 at 10:47 pm
Comments posted to this topic are about the item Held Hostage by the Database
November 16, 2016 at 12:32 am
Today's editorial once again seems to promote the whole DevOps/Continuous Delivery/Continuous Integration strategy. I see this as a good thing.
Personally, I view the restrictions of the data repository used by a system as one way we can limit the work we are required to do. Returning to a system where a data repository is in place only needs a few questions answered:
The degree to which we say yes to the above is the degree to which our hands are tied by the prior selection of the data repository (whether it was by me or anyone else). It is unlikely to be part of our remit to revisit the choice for the data repository without good reason. For me, this is why process, especially automated process, is key to efficient development and maintenance.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
November 16, 2016 at 6:52 am
We need to be careful about trying to design for the future as in our industry the future doesn't always come to be. Then we've wasted coding for it and have junk in our database we don't need.
November 16, 2016 at 7:39 am
Iwas Bornready (11/16/2016)
We need to be careful about trying to design for the future as in our industry the future doesn't always come to be. Then we've wasted coding for it and have junk in our database we don't need.
Absolutely, as you can see I caveated my "future requirements" item. Anyone with a little bit of experience who has been involved in projects after delivery will be aware of how perceived future directions can either drastically change or be cut off.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
November 16, 2016 at 8:14 am
To be honest, I find that such automation is frequently much more complex than certain manual methods and frequently does little to prevent people from overwriting each other's changes to given objects. I've also found that such automation is also an excuse for people not doing peer reviews for form, fit, function, and safety.
No, I'm not saying that automation of database changes is a bad thing. I'm saying that it can be a horrible thing IF your not careful because nothing can promote bad code and mistakes faster than a computer. If you're careful, then it can be a very good thing but you may also find yourself spending some good time updating your automation.
Navigate automation of database deployments carefully because here there be dragons. 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
November 16, 2016 at 8:48 am
Jeff Moden (11/16/2016)
...it can be a horrible thing IF your not careful because nothing can promote bad code and mistakes faster than a computer. If you're careful, then it can be a very good thing but you may also find yourself spending some good time updating your automation...
So true. But if done right, worthwhile.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
November 16, 2016 at 9:22 am
When it comes to choice of database, it helps to understand that some platforms are much better suited for staging large amounts of data (ie: Hadoop or Cassandra), some databases are better suited for persisting session state for a web application (ie: MongoDB or XML), while other database are better suited as the transactional system of record (SQL Server or Oracle). If you're starting a new project, and the team immediately jumps into a debate regarding SQL Server vs. Hadoop vs. MongoDB, then perhaps there is a fundamental misunderstanding about the nature of the data and the it's intended access patterns. First, get the requirements and case usage solidified, and then the choice of database platform will probably be obvious.
Also, personally, I've more often felt as if the project were held hostage by the process itself or the automation / integration tools. For example, if you work in an environment where production deployments (even incident related change orders) must have 24 approval, can only be performed on Mondays and Thursdays, and must get sign off by two different executive managers and the VP of IT, it can be a drag. Also, getting the team up to speed on deploying through something like TeamCity / Octopus is painful.
I've seen more deployments fail because the approval / automation process itself was broken... not because the programming code or data was broken.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
November 16, 2016 at 9:35 am
I think a lot of people make this process way to complicated, identify the components to deploy, deploy them, do it properly. You can automate as much as you want, think up whatever fancy processes you want, fill out forms in triplicate with multiple peer reviews but at the end of the day it's all still subject to human error.
November 16, 2016 at 9:43 am
Eric M Russell (11/16/2016)
...First, get the requirements...
That's it. Slow down. Evaluate. Discuss. Decide.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
November 16, 2016 at 11:16 am
Jeff Moden (11/16/2016)
To be honest, I find that such automation is frequently much more complex than certain manual methods and frequently does little to prevent people from overwriting each other's changes to given objects. I've also found that such automation is also an excuse for people not doing peer reviews for form, fit, function, and safety.No, I'm not saying that automation of database changes is a bad thing. I'm saying that it can be a horrible thing IF your not careful because nothing can promote bad code and mistakes faster than a computer. If you're careful, then it can be a very good thing but you may also find yourself spending some good time updating your automation.
Navigate automation of database deployments carefully because here there be dragons. 😉
Absolutely. It's one reason I try to ensure people move slow, incorporate this into their development and culture, and likely take a year to implement a good dev/CI/CD process. This stuff takes time to understand and become comfortable with.
November 16, 2016 at 11:18 am
Eric M Russell (11/16/2016)
When it comes to choice of database, it helps to understand that some platforms are much better suited for staging large amounts of data (ie: Hadoop or Cassandra), some databases are better suited for persisting session state for a web application (ie: MongoDB or XML), while other database are better suited as the transactional system of record (SQL Server or Oracle). If you're starting a new project, and the team immediately jumps into a debate regarding SQL Server vs. Hadoop vs. MongoDB, then perhaps there is a fundamental misunderstanding about the nature of the data and the it's intended access patterns. First, get the requirements and case usage solidified, and then the choice of database platform will probably be obvious.
Very true. These aren't platforms that work the same way or meet the same requirements.
Also, personally, I've more often felt as if the project were held hostage by the process itself or the automation / integration tools. For example, if you work in an environment where production deployments (even incident related change orders) must have 24 approval, can only be performed on Mondays and Thursdays, and must get sign off by two different executive managers and the VP of IT, it can be a drag. Also, getting the team up to speed on deploying through something like TeamCity / Octopus is painful.
I've seen more deployments fail because the approval / automation process itself was broken... not because the programming code or data was broken.
I think getting up to speed isn't that hard, but it is time consuming. I really recommend a POC on a small project that's an aside to what you normally do. Get everyone to slowly understand how changes can flow through, as well as the places you need to automate, or include manual steps.
November 16, 2016 at 12:00 pm
I find that automation and testability have to be designed in from day one. It's a bitch to try and implement it later.
If you want flexibility then again you have to take design decisions with flexibility as a requirement.
Flexibility is also hampered by failing to address technical debt in a timely manner.
I would also like to point out that buying expensive tools but scrimping on training in the use of those tools is a massive fail. Correct tooling and the knowledge of how best to use them is a massive productivity booster and will pay back many, many times the cost of the tool.
Then there's blame hounding. The DB is blamed for every delay even though business decisions were not made in a timely fashion and had to be repeatedly chased over several weeks.
Gary is right to bring up over anticipation of requirements. IT can be guilty of filling in the blanks. In fairness this can be driven by poorly defined requirements and the lack of interest or commitment by non-IT to get the details defined.
I've found that an effective way to deal with this is to state clearly what is going to be delivered, ask the stakeholders to confirm that the blanks that IT would normally fill in are actually required, and then list the out of scope stuff.
Always remember that IT requirements are also business requirements. You don't have to ask for permission to implement a backup strategy don't descope IT necessities through unnecessary abdication of power.
Viewing 12 posts - 1 through 11 (of 11 total)
You must be logged in to reply to this topic. Login to reply