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 :

http://www.amazon.co.uk/Writing-Effective-Crystal-Software-Development/dp/0201702258/ref=sr_1_1?ie=UTF8&qid=1436357485&sr=8-1&keywords=effective+use+cases

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 🙂

@molgrips

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 are 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 :

http://boost-spirit.com/home/

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.