June 1, 2015 at 2:47 am
Fair play - the cry of 'It works on my machine though!?!' has been heard from my lips on occasion.
These days though I don't think I would ever say that phrase, understanding how irritating it is likely to be. The slightly adjusted 'Let me have a look and see how we fix the environmental factors that are causing this issue.' (or close), which says the approximately the same thing, seems to work a bit better. If anyone has any better formulations I'd be glad to hear them!
One things for sure - there is no code that works perfectly in every circumstance - it's just a matter of how much effort you are prepared to get reasonable behaviour across the board. It's not that long ago that websites we made had to work in IE6 and I'm sure that millstone is still around the necks of a few - glad it's not me though.
June 1, 2015 at 6:09 am
I think, as a whole, people have gotten better at making things work better on different machines. The scalability of database code is one thing, but making front ends scale down to mobile is another story. In my world, clients typically want so much stuff on the screen that it'll never have a prayer of working well on a phone. There are ways, of course, to deal with it, but when we're under the gun to get something done on time, this is usually the first thing that goes out the window.
June 1, 2015 at 7:33 am
That's a big part of why I love being a database developer; I rarely get mired in the muck of "why does the code work on X machine but not Y machine?". Generally speaking, the database only runs on one production machine. Yes, there can be a clustered or distributed environment, but the goal is to make all machines congifured identically; we can simply clone one node from another and then make a few node-specific configuration changes. It's nothing like the technical challenges of getting a desktop application to run across 1,000 individual PCs, or getting a web application to run across 10 different web browsers.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
June 1, 2015 at 8:47 am
I loved the article. It seemed so appropriate for how some software was developed at my previous job. The idea that users would have a different experience never occurred to a number of my co-workers. When the test instance has only a couple hundred of rows in it - of course everything looked and worked okay.
June 1, 2015 at 8:50 am
The DevOps movement is ... bringing automation, scripting, and repeatability to both software development and operational deployment.
I'm curious if/how the 'repeatability' design philosophy includes being able to swop in and out any major commercial or open-source RDBMS and have it work seamlessly with the other software tiers? In other words, if one wishes to use MySQL, or SQL Sever, or Oracle, or PostgreSQL, might it be done without extensive reconfiguration or rewriting of code?
Thanks.
June 1, 2015 at 9:08 am
GoofyGuy (6/1/2015)
The DevOps movement is ... bringing automation, scripting, and repeatability to both software development and operational deployment.
I'm curious if/how the 'repeatability' design philosophy includes being able to swop in and out any major commercial or open-source RDBMS and have it work seamlessly with the other software tiers? In other words, if one wishes to use MySQL, or SQL Sever, or Oracle, or PostgreSQL, might it be done without extensive reconfiguration or rewriting of code?
Thanks.
If that's a requirement, but unless you're an ISV providing a solution that is installed at the client's site, then there is no compelling business reason to design an application that seamlessly works with any RDMS platform. However, if the application is designed to interop with the database through stored procedure calls or web services, then that takes care of 95% of it, even if the assumption from the beginning is that it would only work with SQL Server.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
June 1, 2015 at 9:12 am
If that's a requirement, but unless you're an ISV providing a solution that is installed at the client's site, then there is no compelling business reason to design an application that seamlessly works with any RDMS platform.
Thanks, Eric. I'm not entirely sure about the 'no compelling business reason' argument. If I'm a software vendor and I can honestly state my product works on any of the top commercial or open source RDBMSs, doesn't that give me a competitive advantage in the marketplace? (That's assuming I haven't priced myself out of the market in offering this particular feature!)
June 1, 2015 at 9:26 am
GoofyGuy (6/1/2015)
If that's a requirement, but unless you're an ISV providing a solution that is installed at the client's site, then there is no compelling business reason to design an application that seamlessly works with any RDMS platform.
Thanks, Eric. I'm not entirely sure about the 'no compelling business reason' argument. If I'm a software vendor and I can honestly state my product works on any of the top commercial or open source RDBMSs, doesn't that give me a competitive advantage in the marketplace? (That's assuming I haven't priced myself out of the market in offering this particular feature!)
If you actually are an ISV, then you have a very compelling business reason to support multiple RDBMS platforms. That's why I said:
".. unless you're an ISV providing a solution that is installed at the client's site, then there is no compelling business reason."
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
June 1, 2015 at 9:28 am
I think I'm getting a little soft in the head, Eric; you were correct from the start. Thanks.
June 1, 2015 at 10:22 am
Eric M Russell (6/1/2015)
GoofyGuy (6/1/2015)
The DevOps movement is ... bringing automation, scripting, and repeatability to both software development and operational deployment.
I'm curious if/how the 'repeatability' design philosophy includes being able to swop in and out any major commercial or open-source RDBMS and have it work seamlessly with the other software tiers? In other words, if one wishes to use MySQL, or SQL Sever, or Oracle, or PostgreSQL, might it be done without extensive reconfiguration or rewriting of code?
Thanks.
If that's a requirement, but unless you're an ISV providing a solution that is installed at the client's site, then there is no compelling business reason to design an application that seamlessly works with any RDMS platform. However, if the application is designed to interop with the database through stored procedure calls or web services, then that takes care of 95% of it, even if the assumption from the beginning is that it would only work with SQL Server.
Which kind of gets back to one of the nits I had with the open letter. I am all for ensuring that my code works in a set of "typical use cases and "typical hardware configurations"; that said - if you're sloppy enough to leave me with that wide of a berth and *no* guidance as to how far afield to go, then we rally haven't moved the needle very far in the right direction. If anything - all we've really done is to dump requirements gathering onto the devs, as opposed to making the *team and stakeholders* responsible for determining what the appropriate set of environments and scenarios to set up for.
As much as I like to rely on the ole SQL Crystal Ball (I think Brandy has ours for the week if I am up on the Thread), most developers only have a fuzzy understanding of what the spread of configs and environments might be they need to cover. My job to make sure that they work, NOT guessing which ones I should test for.
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
June 1, 2015 at 4:55 pm
I think referring to an open letter to engineers without also referring to John Bentlry II's open letter to Product Managers in response to it, Your Job is to Define the Product is a mistake. Nevertheless, it's a great editorial and I rate it 5 stars because producing software that will work in all sorts of environments has almost always been a very important part of what I do and because I really believe that most software is badly engineered through paying no attention to the range of environments it has to work in.
A big defect in Laura Klein's letter is that it doesn't remind the sofware engineer that an important part of his job is to deny the product manager the ability to wreck the project by insisting that something categorically impossible is an absolute requirement and destroying all attempts to get a reasonable requirement specification; another is that it fails to remind software engineers not to tell the product manager that some idea they've had that requires extensive pure research (since we've no idea at all how to do it) can be done in a couple of months; but the biggest defect is that it seems to work from the point of view that all failures to deliver a sound product are attributable to software engineers, instead of instructing product managers to do their jobs and not leave it to software engineers to attempt (sometimes futilely, when the product manager is totally irresponsible - not so rare a situation) so that project success is possible if the software engineers also do theirs.
Tom
June 1, 2015 at 5:22 pm
Eric M Russell (6/1/2015)
That's a big part of why I love being a database developer; I rarely get mired in the muck of "why does the code work on X machine but not Y machine?". Generally speaking, the database only runs on one production machine. Yes, there can be a clustered or distributed environment, but the goal is to make all machines congifured identically; we can simply clone one node from another and then make a few node-specific configuration changes. It's nothing like the technical challenges of getting a desktop application to run across 1,000 individual PCs, or getting a web application to run across 10 different web browsers.
That happy situation probably applies only to database developers in companies who are developing databases for in-house use only.
When you are building a database (and applications) that will be used by a large number of customers all around the world with a wide range of workloads, an equally wide range of balances between different workload components, and an enormous range of different of competence of the customer's IT staff, life is somewhat different. Why does this code work on that 2 server configuration in Mumbai but give us problems on that 1 server configuration in Barbados? Why does it work on this one server configuration in Qatar and this 3 server configuration in Dubai, but cause problems on this 2 server configration just outside Dubai? How do I persuade this customer in Egypt (a salesman can't persuade him, the customer needs a technical explanation) that he must make an exception to his IT purchasing policy and buy hardware I recommend instead?
Tom
June 1, 2015 at 5:27 pm
That happy situation probably applies only to database developers in companies who are developing databases for in-house use only.
Indeed, as Mr Russell explained to me already (twice).
😉
June 1, 2015 at 6:54 pm
GoofyGuy (6/1/2015)
That happy situation probably applies only to database developers in companies who are developing databases for in-house use only.
Indeed, as Mr Russell explained to me already (twice).
😉
Well, he allowed ISVs.
But itt actually applies to some other businesses too. Most of my working life was with ICL, who certainly weren't an ISV but certainly did have most of the issues I mentioned; some was with CTL, who also weren't an ISV and also had these problems (albeit to a lesser extent), and some was with Neos Interactive which was partly an ISV but mostly a provider of entertainment (films, music, TV) and had most of the local/individual customer problems in all aspects of the business. So the vast majority of my experience is in firms which suffered all the problems that Mr Russel claims are only suffered by ISVs, despite none of those firms being ISVs.
Tom
Viewing 15 posts - 1 through 15 (of 19 total)
You must be logged in to reply to this topic. Login to reply