Brainiac4, it is likely that what is now called “functional test automation” and involves massive amounts of high quality software engineering work will later on diffuse and become more “democratized” through lines of thinking about QA similar to mine. At least, if somebody gives a damn about researching the topic. More powerful and easy to use tools do appear with time, or at least that used to be the case so far. That does not prevent the pros from believing themselves to be at the plateau of development of the discipline, leaving only the Zen-like mastery and not quick-and-dirty hack tools worthy of being sought.
I am not qualified to comment on your desire to subdivide the universe of all software shops into those 2 categories. I hope that it is not as valid as you claim, but in this day and age, who knows.
err, never mind, I read either the wrong article or dyslexic one. “Functional test automation” seems to map onto either scripted testing of a web app or onto “write a unit test for the presenter in MVP pattern” for desktop apps.
What I’m trying to illustrate (and failing, I guess) is that there is a fundamental decision point: you either care about code quality or you don’t. It’s certainly possible that shops that care about code quality will still produce shitty code, but there are methods and processes (and tools, but the methods are more important) to help guard against that. And it’s possible (but very unlikely) that shops that don’t care about code quality will produce good code; that’s likely going to be the work of individuals who code well despite lack of organization belief in things like unit testing and continuous integration.
It’s like saying “look, you either care about personal hygiene or you don’t, and which decision you make is going to strongly influence the outcome.” There aren’t just two outcomes, but the vast majority of outcomes are going to fall into one of two sets: stinky or not stinky. And when you’re contemplating whether or not there’s a market for your product, I figured you might find it useful to know that both of the two primary types aren’t likely to want it.
Where I work, we have a giant codebase full of copy/paste, needless obfuscation, magic constants and other crimes. It has no unit tests to speak of. It got that way because we decided to measure developers by hourly rate instead of by the quality of code produced. When that was the reigning paradigm, your putative “band-aid” solution would have been seen as needless expense.
We’re in the process of fixing the problem, with changes in methodology and tools. Now, your putative band-aid would be seen as insufficient to our needs.
As I see it, you need customers who have a problem, know they have it, want to fix it but don’t want to spend much on it. That seems like it should be a reasonably large market, but in software development, by the point in time people are admitting they have a problem, they need real solutions.
I’d guess you could find customers - it’s a big world - but you may not have a really big audience.
Have you considered doing some Lean Startup-style testing of your idea? You’d get better feedback than you will on a message board.
No, they wouldn’t. You really need to spend time in a large development environment. False positives are a huge time suck, and will quickly result in the tool being discarded or ignored. Training is a huge time suck, since these concepts aren’t simple. If they were simple, we wouldn’t need band aids. Either your tool finds obvious stuff in which case it’s not really needed, or your tool is complex and subtle, which requires training and generates a lot of noise unless configured precisely for the environment.
Lots of smart people have developed many software products that are clever, inexpensive, and useless. It’s not an easy problem to make something that is both lightweight and helpful.
or maybe stuff that will be obvious once somebody tells you is not obvious up front. Cotton gin was “obvious” once demonstrated. Before it was demonstrated, it became apparent there was a whole region that could have been producing cotton but didn’t.
To cite an example closer to home, the memory debugger like Purify is pretty obvious now (not necessarily easy to build, but the idea is “obvious” and its output easy to understand). Was it obvious before the first system of that class was developed? Perhaps people would have had all sorts of objections to such a hypothetical tool, and not just based on “computers are so slow in this year 1970 (or whatever) that nothing of this sort could ever fly”.
OTOH, I also recognize that a tool can be more useful to some than to others. E.g. .net debugger is not useful to me because of my adherence to good logging. But it is still useful to many people. Both logging and debugging are limited tools that give no “guarantees” during development. Each tool works good enough for people who like it. That does not make any of them a panacea, and that does not make any of them useless (except for those that, hypothetically, are useless for the vast majority of the potential users).
Brainiac4, so things blew hard enough on the management to induce major restructuring? Now, let’s imagine hypothetically that things blow up on somebody else but there is not enough money for the ideal fix. What are they to do?
Your post could also be taken as a description of “major restructuring after messed up legacy” market niche. Presumably that may benefit from better tools too, even though it can certainly be pulled off with diff, plagiarism detector analyzer and lots of notes.
I guess there is no shortage of topics of PhD dissertations floating out there once we get out of the narrow bubble of personal experience enough to see recognize them.
it’s supposed to be a hypothetical discussion, intended to identify what sort of tools would make sense . As well as what market niches exist, in which sense I appreciate inkling’s input because he pointed out (however vaguely) a situation I have not thought of. As well as any other useful info that can be gleaned.
Telemark, to get closer to answering your question, I am generally willing to discuss ideas that are either sufficiently abstract, sufficiently hard to spec out and implement or sufficiently trivial (an example of trivial is a recent thread of mine on making a tool to detect why a tuple is not in query result - pretty trivial because it would be nice but non significant even for CRUD day-in-and-out programmer). Do I need to explain why I don’t wish to discuss non-trivial, not-that-hard-to-implement ideas?
If one of these ideas can be described as “Red Gate database diff 2.0 - new, improved and more powerful; details available under NDA”, I don’t think you would be satisfied. But there is only so much detail that can be published on sufficiently simple inventions. E.g. if Red Gate did not exist and somebody were to have this brilliant idea “let’s just extract db contents and run diff on them”, should this guy have been running around screaming this on the streets? Or maybe he should have been founding Red Gate or otherwise trying to profit from the idea by whatever mechanism?
My point is that you need to identify concrete problems that you are trying to address. There are lots of software products that claim to address problems like you are vaguely describing but they don’t work well, are expensive to implement, are a pain to maintain, or only find stuff that a moderately well-trained cocker spaniel would find.
You seem to be saying that if you could identify low hanging fruit that no one else has found, you could harvest it for me. I’m not convinced that such a fruit exists.
Telemark, well, by talking here on SDMB I am trying to identify problems. It’s hard to do this concretely here, but I am trying. It sure is better than nothing, i.e. better than only thinking of info I can glean from my own environment. From my own environment I can glean that Red Gate sucks (ok, sorry for mentioning them again and again, I know) but I cannot learn much about problems in a big shop. Or in a small shop with big Indian facility. Or a shop that gets gouged on a 3rd party support contract. Anyway, you get the idea - all of us together know more and can share more than any of us alone.
I am not sure in what spirit this is being said. Are you a PhD candidate, a Microsoft Research exec or similar type of guy who actually needs fruit of some sort (low hanging, high hanging or what have you)? Or do you have no business interest here and ask as part of the general discussion format?
I also am surprised at your (seeming) strong stand against the possibility of “any” significant improvements “anywhere” (if that’s not your stand, please clarify). I mean, world is a complex place. Some people are more observant and clever than others. A lot of “research” in universities and quasi-university corporate institutions is driven by fads, divorced from real world realities or “globally outsourced”. A lot of managers and “management consultants” have a well-earned place in Dilbert. And so on. That all adds up to an environment where we would expect to see plenty of inefficiencies, some low hanging and some not so.
to add to the above, and this does not directly relate to the two of us as software professionals, notice that some fields out there may be still insufficiently computerized. There was a time when accounting was done on paper. That’s no longer the case, although whether or not their software has truly plateaued near the Platonic ideal (sort of like web browser - imperfect but really, really good at handling the typical case) I am not qualified to say. It may be that there are other fields where existing software is really primitive and nobody notices because professionals in that field do not think like engineers or don’t think, full stop - there are such fields too. Well, education of various kinds is a textbook case - little useful software, plenty of quacks that everybody is tired of and a lot of dumb “professionals” from whom nobody in his right mind expects any good.
I’m a technical project manager with 25 years of experience in software, from small startups to multi-nationals. I’ve worked in many development environments and have seen many (many, many) software packages advertised and sold as quick fixes, simple steps, etc, and they have always over promised and under performed. Is it possible to create something that bucks the trend? Sure, and people have done so. Is it easy, quick, and cheap? No, it isn’t. There are many clever people who have attacked this problem and no magic bullets have been produced.
That’s not my stance. There are incremental fixes that can be applied to any process. Certainly the software development world can use them. My assertion is that if a development process isn’t committed to doing the hard work required to build well defined and tested code, no simple fix is going to have an appreciable impact on the bottom line or on code quality. Software development is too complex and varied for any simple product to have a significant impact over a wide range of environments. There are lots of tools out there that are pretty simple and work well. But to take advantage of them you need to integrate them into your work flow, establish development guidelines, and then enforce those guidelines. Without that effort and commitment, no magic bullet can work.
The companies you described in the OP won’t benefit from these tools because they lack the commitment to invest where it is really needed. Once that commitment is in place then these tools can be used, but those kind of tools are usually already in place in those companies.
I do not dispute the impossibility of magic bullets, as per No Silver Bullet thesis. Tools already on the market are not magic bullet, and tools that will be on the market ten years from now will not be magic bullet either.
I think that at this point there only real disagreement is on the “significant impact” issue. Which in itself is a notion open to interpretation and which does not, contra Telemark above, need to " have a significant impact over a wide range of environments" because any given bandaid could just as well have some useful impact in only a few environments (assuming that for any given environment there are a large number of shops that have it).
Conceivably even the need for the “significant” part could be eliminated if we were to reformulate the task as making a tool that makes a single programmer’s or manager’s life a bit (or even a whole lot) easier and that could be installed and run by that same single programmer or manager without seeking input from colleagues. Of course, that starts running into the problem of conservatism of programmers and depresses the possible price that could be charged.
So in a sense it becomes a question of marketing - selling a $20 thingie to 100K people (with the understanding that once you have managed that, you got a brand and can sell various other things to other constituencies for other prices) can be the best or the worst business strategy imaginable, depending on how good is the marketing channel. And when it comes to an individual splurging $20, the “significant impact” becomes even more subjective than it was previously.
Then again, maybe $20 thingies for programmers or their managers are not a good way to invest effort because what if there is more money to be made selling thingies for nurses; or non-programmer middle managers; or students; or whichever other category of people - but such lines of inquiry would deserve their own threads.
For the time being I think I will just concentrate asking further specific questions about different development shop situations, to avoid the “wide range of environments” issue. That would both constitute a source of at least anecdotal information on not-often-discussed topics (just because HowStuffWorks does not have an article on “small robotics company” or “COBOL shop working for a large utility” or “Microsoft facility at Bangalore dedicated to such-and-such product” it doesn’t mean that such info should not be available online) and also may uncover local niches where the need for bandaid tools would be particularly obvious.
. As well as what market niches exist, in which sense I appreciate inkling’s input because he pointed out (however vaguely) a situation I have not thought of. As well as any other useful info that can be gleaned.