You don't need to be an 'investor' to invest in Singletrack: 6 days left: 95% of target - Find out more
If you know you will be unit testing stuff then it encourages lots of good healthy design/programming principles (loose coupling, IoC, SOLID etc) that make the resulting code better.
You *should* be doing that anyway.
So you're given a fixed amount of time in which to complete a project. You don't tihnk it's enough - do you just refuse to do it?
It is like stepping back in time a decade or so - I thought these arguments were over 🙁
As a developer with a fixed amount of time I have to think which is the most likely way to meet that time frame.
I need to do comprehensive analysis on the problem to ensure I have everything covered. That comprehensive analysis will normally be an identification of the various use cases that I have to meet.
I figure out how I am going to address each use case, and how I can prove that I have addressed it.
Ideally I want to automatically prove that I have met it.
In order to do this I need to architect my solution so I have testable components - which is one of the strongest arguments for TDD, it forces you to produce a well decoupled system so that it can be automatically tested.
I then have a list of tests to meet - I can measure my progress based on the number of tests passed.
It takes discipline and the trouble is that it can be too late to go back and impose the testable design once you have started building a system.
But it can also be difficult determining everything that needs to be tested without having written some code and gained experience of the domain. Catch22 a bit.
Anytime I have rushed in I have regretted it - but anytime I put the upfront investment in to produce a highly testable system I haven't, I have been grateful for it as it has massively helped me produce a stable system to time.
If anything, not having the tests is by far the riskiest proposition as then I am facing the possibility of not being able to meet a deadline because of the number of issues I have to clean up, which would have been caught by the tests.
Read this book for the use case analysis - it is excellent and you won't find a more lazy programmer than me :
But it can also be difficult determining everything that needs to be tested without having written some code and gained experience of the domain. Catch22 a bit.
The value of spikes; hack some code around to figure out what/how something needs to be done. Then write tests from the knowledge and then implement.
Academically pushing the TDD principle is not helpful.
Unless you are a domain expert you can't necessarily identify all the things to test in the first place.
So whereas TDD might be an ideal, you might have to be pragmatic about it. And you might even have to 'start again' once you have written some code to explore the problem.
So test coverage is more the ideal to strive for.
But there is a big risk of ending up with stuff that is not testable if you start coding early, and not being able to come back from it. The more untestable code there is, the more the risk of project runaway.
I read a Dependency-Injection book the other month and he was designing his system top-down within the Ioc Container, which seemed a good idea.
He was ending up with a production-ready prototype that was runnable in the test framework.
I'm not writing java, incidentally. Or any other 'language'.
I have no way of creating what you would describe as unit tests.
I read a Dependency-Injection book the other month and he was designing his system top-down within the Ioc Container, which seemed a good idea.
Absolutely - and agree on the academic pushing of TDD.
The reality is that some people write well structured testable code; with good IoC principles; SOC and all that stuff and never go near a unit test framework.
And some people evangelise about TDD and write terrible code.
And every combination in between 🙂
Out of interest then ... what do you write in ?
For reference; I'm principally a C# guy theses days; but also use Ruby (we used this as a basis for a DSL that we created) and Java.
You *should* be doing that anyway.
Indeed, but most of that good stuff doesn't give an immediate payoff, so it is easy for it to get pushed aside as people hack stuff together for a deadline.
But if you are writing unit tests then a good design immediately pays back with easier tests.
I'm not writing java, incidentally. Or any other 'language'
What [i]are[/i] you doing then? Colouring in?
I am currently doing a form of delcaractive programming, as opposed to the usual procedural languages. So testing has to be scenario based. It's quite hard to explain to people who only think in traditional procedural terms, or whose organisational rules are set up along those lines. So you get beaten with this unit test stick a lot, which is why I have learned a flexible approach over the years. Not at the expense of quality, of course.
You need to choose the right approach for your project - not what the books tell you is right. But you still need to read them.
I am currently doing a form of delcaractive programming
You're doing SQL ? Why didn't you say 😉
Seriously though - a bit more information might be nice - what tools etc. That came across as a *little* condescending.
I am currently doing a form of delcaractive programming,
hmmm, like C++ templates then 🙂
see boost spirit :
there was someone who wrote some C++ templates that wouldn't compile, but the error message included the expanded class name and the generated prime number sequence - so the result was produced by the compiler.
hmmm, like C++ templates then
No, nothing like that. Event based programming using a tool.. can't say any more on the internet for reasons that would be obvious if I did.
Event based programming using a tool.
That doesn't sound hard to unit test at all. In fact it sounds perfect.
Mock the back-end and siblings, inject events, check results.
I have worked in a lot of institutions with unbelievable levels of incompetence (it seems investment banks value it...) so the fact that you continue to work in that antiquated way doesn't surprise me.
There is nothing like going to a client and being introduced to a wizened old developer who everyone in the company looks to for advice; and then you quickly realise he has only 2 years experience repeated 10 times 😉
No, nothing like that. Event based programming using a tool.. can't say any more on the internet for reasons that would be obvious if I did.
seriously ... ?
That sounds dangerously close to "If I told you; I'd have to kill you"
I know nothing about where you work; what it is you actually do; just that you are doing some declarative stuff that'd be too difficult to explain to "you stuck in the mud procedural coders" and you can't even put a name to the tool you use ?
just sayin' 😉
There is nothing like going to a client and being introduced to a wizened old developer who everyone in the company looks to for advice; and then you quickly realise he has only 2 years experience repeated 10 times
The last one of those I dealt with had attained his lofty position by completely mastering the art of being able to lie with absolute conviction.
that'd be too difficult to explain to "you stuck in the mud procedural coders"
No, it's not difficult to explain at all (although it is difficult to do), and I wish I was procedurally coding currently.
If I explained it you'd figure out where I work and what job I do, which isn't something I want to make any easier on the public internet 🙂
Mock the back-end and siblings, inject events, check results.
It depends on how you define a unit. Programming is done by declaring events, mappings rules and further events and further mappings etc. You can't test one event and mapping on its own (which would be unit testing), you can only give a series of input conditions and test the output conditions. If you don't get the expected conditions there is no way of telling which link in the chain has gone wrong. Or, if you DO get the expected conditions, you don't know if it's actually all correct or if two failures have cancelled each other out.
I call this scenario testing, it's not the same.
If you don't get the expected conditions there is no way of telling which link in the chain has gone wrong. Or, if you DO get the expected conditions, you don't know if it's actually all correct or if two failures have cancelled each other out.
That sounds like a remarkably good argument for separately testing the individual links in the chain (aka "units") in osiloation!
I call this scenario testing, it's not the same.
sounds like integration testing to me ...
Yes, but that's not technically possible Graham.
sounds like integration testing to me
Integration testing is when we connect it up to all the other components and see if it works.
Functional testing is when we push test cases through the front door and see what comes out the other end.
thread did kind of drift a bit.
was wondering more if the OP issues were more the toolsets and concepts of multi-user code maintenance and the like, or the code?
don't think anyone can say how long a ticket takes to open, evaluate, or close out. every field is different. I'd imagine something in the financial sector might be significantly shorter duration than aerospace for example (just as an example one that we identified a month back is probably on about 8 week turnaround and will be bundled with several other tickets, but is probably quoted as 12 hours work, but in reality is little more than 2 minor changes to an XML config file, and 11.5 hours of "running a few tests" and adding the change to the delivery note).
certainly seen some very gash programming in my time. and that's stuff that has been tested, has passed QA, has been delivered. GUI forms that have all "not yet implemented" buttons attached to gtk.quit() or attached to "create a core dump".
worked mostly in embedded stuff myself, and I'd say most of the issues arise from obscure combinations of external stimuli that had been overlooked. and in some cases, stimuli that will never occur on a test bench (unless anyone has some kit for firing high velocity protons through RAM chips aiming at memory locations where the linker file states there's a tight loop?)
maybe TDD might help? that bit of code was clearly from the student intern, an surely that's the fashionable methodology of profs right now?
If I explained it you'd figure out where I work and what job I do, which isn't something I want to make any easier on the public internet
Given all your previous threads about encrypted HDs I'm guessing some MoD / DoD proprietary language. Missile guidance systems etc.
that's not technically possible Graham.
So you have an event-driven architecture where you plug together module to form a processing chain - but you have no way to fire just one event at just one module? No way to create your own mock/stub modules? And no way to intercept the messages between modules?
That is seriously messed up!
I'm guessing some MoD / DoD proprietary language. Missile guidance systems etc.
I really hope not!
don't think anyone can say how long a ticket takes to open, evaluate, or close out. every field is different
you can say if you are working in a scrum/agile environment - you need to trim your ticket content down/isolate use cases such that the granularity of the tickets fits into a sprint cycle.
Otherwise you sort of lose the point of the process, which is really about define small chunks of work to be delivered in defined, short, timelines, and keeping levels of 'focus' and 'panic' constant throughout the process.
The difference between agile/XP and some of the older methodologies is that these seems to have come from experience of what works and what doesn't, i.e. what is most likely to succeed.
it was Jon Copliens organization patterns that triggered this move, a bit like software patterns identifying common architectural patterns that were used in successful solutions to a problem.
You then have other methodologies building on these to increase the amount of process and provide careers for people that are self-professed experts in them.
Please stop guessing, in case you are right 🙂
That is seriously messed up!
You don't know the half of it!
I didn't make the tool, but the client bought it.
I really hope not!
so do I !
Sounds like a deficient tool if you ask me.
Windows Workflow can do all that, and looks pretty, but in reality the time 'saved' upfront is moot - you would be far better off with something that might take a bit longer to write but can be comprehensively and automatically tested.
Anything that involves manual intervention rules out things like soak testing, etc, which you really need for any sort of a complicated, event-driven, asynchronous system which normally are very hard to prove formally.
To the OP, this thread is reason enough to run screaming from development as soon as you can, surely?
Given all your previous threads about encrypted HDs I'm guessing some MoD / DoD proprietary language. Missile guidance systems etc.
In which case working at a snails pace and being able to closely inspect the contents of ones fingernails are the core requirements; actually being able to get on and do some work is secondary 🙂
Not that this is the developers fault, but they can't work without the database and it's going to take at least 3 weeks for the request for the new instance to be processed by the highly efficient managed service partner, another week for an engineer to be assigned, a couple of days to figure out that the engineer doesn't know how to install it, and then 5 weeks for them to accept the bids from the consultancies that do know how to do it. When it finally arrives, said developer has worked out that persisting the data isn't actually required and the project manager has de-scoped the requirement to protect his unicorn...
Sounds like a deficient tool if you ask me.
It is, very much so. I asked on my second or third day to be allowed to write it using Message Broker, Java and BRMS but was told no.
Let me repeat - I did not choose this, it was forced upon me.
Let me repeat - I did not choose this, it was forced upon me.
Sounds like some manager wants a project with that product on his CV...
There's a long history, to do with salespeople, clients, consultants, analysts and scope change.. and on top of this the product turns out to be bug ridden and shit in every possible way. Except performance, it's quite quick.
Wow, sounds like software development has changed a fair bit since I did it for a living. Sometimes literally it was specs on the back of an envelope and testing was what I saw fit. This was at what was one of the biggest software houses in the world (at the time, and i'm not sure how they measured the size).
It varies a lot by organisation. It also depends what's driving your project. If you're doing a project for a client on a fixed price, the price will be beaten down as low as possible, so you'll be under great time pressure.
If you're employed by a business for an internal project and their success depends on it, they'll ask you how long it'll take and will (or should) be prepared to give you as much time as you need to get it right - within reason. They'll probably still pressure you but it'll be so they look good to their managers/shareholders...
If you're making a product for market, delivering it before it's ready will seriously damage the reputation of the company so they'll delay it as long as it takes to get it right. Unless it's a widely anticipated product and the marketeers need it ready by Christmas to keep up with the competitors.. in which case you'll be under pressure again.
Nowadays you have a lot more frameworks from which to leverage power - the only problem is that they are large and you don't really want to become an expert in it as another one will be along in a minute...
A lot of programmers without much technical depth it seems.
You use google a lot to look for solutions utilising those frameworks that you don't really want to become an expert in, which makes the problem worse as you forget the answer once you have used it.
And that is in addition to the problem that has been around for a long time, in that if you have a technology to use, you normally encapsulate it in a sensible OO layer of abstraction that is suitable for your domain, and then you use that abstraction - so you never become an expert in that either, despite years of use.
There are some interesting tools out there - like IOC containers that relieve some of the feeling of being sloppy by relying on the garbage collector to clean up after you.
And the testing world has become a lot more sophisticated.
The saying that a good programmer is a lazy programmer still holds true - such a programmer will embrace all the new auto testing stuff as they don't want to be bothered with the hassle of fixing bugs later on in the process or in production (!)
I think it seems that older people are less willing to learn, but really they are less willing to keep learning redundant stuff that is going to get replaced shortly anyway.
I hire engineers based on an 'are they smart and do they get stuff done?' policy. You lot fail the latter because you just spent the whole working day having a p***ing contest over tools and methodology. I suspect you are too far along the spectrum and also like to align the writing on the tyres with the valves. jfdi and go ride your bikes.
Love Jono xxx
Nowadays you have a lot more frameworks from which to leverage power - the only problem is that they are large and you don't really want to become an expert in it as another one will be along in a minute
I always thought that was the best thing about Java - the language is standardised but so are most of the APIs. And new innovations are brought into the language and made standard as it grows.
I suspect you are too far along the spectrum and also like to align the writing on the tyres with the valves. jfdi and go ride your bikes.
I am not at all anal about my bikes - as long as they work.. never lined up a valve in my life. My code is the same - absolutely fit for purpose, and nothing more. If it needs to be generic and extendable, then it is, but sometimes being done quickly is more important. Sometimes (and this is something the hardcore geek types can't stand) you can write something quick and simple that doesn't run as fast as the intricate complicated fine tuned stuff, because hardware can be a lot cheaper than developer time.
leverage
/me starts checking off the management speak bs bingo card.
fricking hate that word. and synergy. and I particularly loathe "COTS".
You lot fail the latter because you just spent the whole working day having a p***ing contest over tools and methodology
😀 I got plenty done today thanks. And I don't consider talking to fellow engineers about tools and methodology to be a waste of time either. I'd be a pretty crappy engineer if I did.
I always thought that was the best thing about Java - the language is standardised but so are most of the APIs. And new innovations are brought into the language and made standard as it grows.
Not sure how that differs particularly from other common languages? Even C has an agreed standard and supporting libraries, even if it is a bit lower level than some.
My code is the same - absolutely fit for purpose, and nothing more. If it needs to be generic and extendable, then it is, but sometimes being done quickly is more important. Sometimes (and this is something the hardcore geek types can't stand) you can write something quick and simple that doesn't run as fast as the intricate complicated fine tuned stuff, because hardware can be a lot cheaper than developer time.
Nothing wrong with pragmatism. Agile positive encourages it. And premature optimisation is a common problem too, sometimes at the expense of code readability.
But on the other hand, the stuff I write needs to be beyond "good enough" because if it goes wrong then people can die (or worse, sue!) so while being generic, reusable or extensible often aren't important goals for my work, being testable absolutely is.
Likewise efficiency does often matter to me because I'm often dealing with microprocessors with low clock speeds and storage and RAM that is measured in kilobytes.
I spent all day trying to figure out how to configure this crappy software.. unfortunately I'm supporting it as the expert.. good job I'm so good at my job that I can solve problems...
Not sure how that differs particularly from other common languages?
Ever used C++?
But on the other hand, the stuff I write needs to be beyond "good enough"
That's an oxymoron. In your case, good enough is simply a higher standard.
I appreciate that about your code - that's what I've been saying all along. Requirements means much more than what your code needs to do.
same as what graham said.
we're up to 2Mbytes EEPROM and RAM now 🙂
oh, about 1.7Mbytes of that is config data.
and we pretty much turn off all optimisation, so is pretty easy to debug raw disassembled code.
if anything needs throughput performance then it's FPGAs usually.
not a hope in hell's chance of Java coming any where near those processors. used to be TLD1750, now Sparc8 based Leon32 SOC.
Tools for jobs innit.
I used to work on AS400s, the OS didnt actually have any way to handle running out of storage gracefully, the machine simply crashed. The solution was always just to add storage.
That's an oxymoron. In your case, good enough is simply a higher standard.
You get what I mean though yeah, different strokes and all that. I've certainly worked on plenty of stuff where a pragmatic, "good enough"=="it doesn't crash horribly" approach is perfectly acceptable too.
Ever used C++?
Same thing? It is a standardised language and it has a set of standard libraries.
Just there are lots of additional non-standardised libraries and frameworks available in addition to that standardised core.
I appreciate that about your code - that's what I've been saying all along. Requirements means much more than what your code needs to do.
Yep. And that's what I meant when I said that TurnerGuy's test might be a good one for his job, but not yours.
Same thing? It is a standardised language and it has a set of standard libraries.
No, not really, it has several standard libraries, at least it did when I was using it - a long time ago, and not for long.
When writing code for Windows you had a choice of platforms, never mind Linux or any other nix. Far less of an issue with Java - almost a non-issue.
This thread is why I stayed in academia and pretend to be a computing scientist.
No, not really, it has several standard libraries, at least it did when I was using it - a long time ago, and not for long.
You've made it pretty clear that you weren't very good at C++ 🙂
It does have a standard library, and the standard template library, and boost, which is stuff that will probably end up on the standard library but hasn't because of the standardisation cycle.
C++ is a great language and an awful lot of the good ideas on other languages came from it and the people involved with it. The main problem is it's verbosity.
Java libraries are not standardised, there's always new frameworks coming along.
A book I read a while ago said that you could add up all the frameworks in every other language and you would still have less than there are in java.
For example, Spring is popular partly because of the complexity of ejb and it's configuration. And there are many parts to to Spring. We are having trouble finding experience of the parts we want.
The trouble with relying on some of these open source frameworks is that people move on to develop other frameworks when they get bored, or competing frameworks when they have disagreements with other framework developers.
It does have a standard library, and the standard template library,
Yeah but if you are in Visual Studio there's the Microsoft one.. and the STL only does basic stuff.. so if you want to open a window, you have a variety of choices.
Java libraries are not standardised
There are quite a lot of JSRs, IIRC... And yes, there are APIs out of the standard but plenty in it. Hibernate got absorbed into the standard for starters... then the dependency injection stuff too..
We are having trouble finding experience of the parts we want.
How important is that direct experience? Why can't you offer it on the job? How long does it take to pick up a framework?
The trouble with relying on some of these open source frameworks is that people move on to develop other frameworks when they get bored, or competing frameworks when they have disagreements with other framework developers.
True. That's why it's good to have these things in a JSR - but then again, JSRs come and go out of fashion too. But at least they're supported for a while.
properly scared the OP away from the industry now 😉
properly scared the OP away from the industry now
if you take to development then it is still pretty good as it it one of those activities where you produce something and can take some pride in it.
A bit like a civil engineer building a bridge - the difference is that our bridges are often a bit wobbly but we can patch them up later...
if you take to development then it is still pretty good as it it one of those activities where you produce something and can take some pride in it.
One of the things I like with my embedded work is that I can point out something in a shop and say "I made that".
It's a lot more tangible than work I've done on business systems and the like.
It's also about the only time my wife, kids and parents get close to grasping what it is I actually do. 😀
You've already used my code several times today without knowing it 🙂
Ah, so it [i]is[/i] missile guidance then.
That was a reference to a few projects ago - financial transaction hub I had a small but central part in. That I can talk about 🙂
Helped write a TV program authoring system. For the Japanese market - unlikely to see the fruits of *that* (and testing was interesting !!)
And DVD authoring system, so that's more tangible I guess.
I never really got programming either. Did a Pascal evening course for a while, sort of understood things but when it came to writing my own bits I quickly got out of my depth. A few months later I got my first job which was as a VAX/VMS operator/Powerhouse programmer. I was fine at the ops stuff just crap at the Powerhouse 4GL programming. My next IT job was a Wintel consultant and I've never looked back (that was 18 years ago), although I'm now trying to avoid powershell scripting...
Well, I wrote a computer teaching program for Strathclyde Region primary schools, to teach children basic maths, spelling and grammar. On the BBC Micro. When I was at primary school.
So there 😀
One of the things I like with my embedded work is that I can point out something in a shop and say "I made that".
that's pretty much my philosophy, except in my case it'll be "see that barely visible bright white dot zooming across the night sky" (except for the one that is 45 light minutes away, where you'll just have to see it every time it's on sky at night).
I hire engineers based on an 'are they smart and do they get stuff done?' policy. You lot fail the latter because you just spent the whole working day having a p***ing contest over tools and methodology.
+1. I had a team member recently (who left a couple of months ago) who whilst technically adept, always became obsessed with the minutiae of writing perfect code. He'd spend hours obsessing about non-important issues when he'd already solved the problem. It had me tearing my hair out on numerous occasions.
whilst technically adept, always became obsessed with the minutiae of writing perfect code
Did he ride a Turner by any chance?
Did he ride a Turner by any chance?
well it wouldn't be me - look back at my reasoning for TDD and the fact that it helps you meet you release goals without necessarily having perfect code.
If something has to be coded up in a non-optimal way to meet the deliverable then it doesn't matter - the importance is that the test works.Once delivered you then refactor to make the code better, before you build on it again - otherwise the entropy of the system will increase.
If a code review at the end pointed out that you had done it the wrong way or that the code was iffy, then so what? Any code review is at the start of the next phase, probably with your pair as you design it.
If I am writing code that will be in a multithreaded/asynch environment I will stress a bit more about the code being right - it is still pretty hard to properly test such code so you will be doing you best to write it correctly in the first place.
Did he ride a Turner by any chance?
😀 Get over it mol.
The aptitude test he posted had two very obvious bugs in it that would definitely cause issues in the software.
Spotting that is really not being [i]"obsessed with the minutiae of writing perfect code"[/i] - it's just producing code that works correctly.
Sadly too many "JFDI" managers would be happy to accept that code because it appears to work and would pass a naive unit test with 100% code coverage.
Get over it mol.
I'm just having a laugh...
I think I've worked it out - molgrips is working for United Airlines ?
http://money.cnn.com/2015/07/08/news/companies/united-flights-grounded-computer/
😆