245 reputation
15
bio website
location Reading, United Kingdom
age 28
visits member for 3 years, 6 months
seen yesterday

Jan
21
comment Parser and interpreter knowledge as a way to gauge programmer ability
+1. Correlation does not imply causation. Good programmers often like parsers and interpreters because they're interesting programming problems - to them.
Dec
19
comment Is TDD viable in collaborative open source projects
Ah, I see what you mean. I suppose some loss of rigour is inevitable, but you can still verify that code comes with tests, that the tests are sufficiently granular and they cover everything they're supposed to. I'm not that familiar with git, but for a given pull request, is it possible to inspect the sequence of commits for that changeset to see that the developer followed a suitable process to produce it?
Dec
19
comment Is TDD viable in collaborative open source projects
Surely the repository owner can decline to pull any changes that don't conform to the project's quality standards? Perhaps the quality and quantity of contributions would suffer if contributors dislike this, but that;s not to say you can't enforce it. Surely?
Jun
22
comment Should we design programs to randomly kill themselves?
I don't have anything useful to contribute as an answer, but this is definitely an interesting question. It would definitely force a programmer to write a decent component architecture that (correctly) copes with random component failures if those failures were guaranteed by the nature of the components themselves.
Jun
16
comment Prototyping vs. Clean Code at the early stages
Can you suggest what you think the problem is? Perhaps the sentences are too long, as I've just noticed there are only two of them. Anything else?
Jun
1
comment How do you get consistency in source code / UI without stifling developer's creativity?
"Bosses don't really ever seem to care about the quality of the code" - most bosses who aren't imbeciles realise that quality is important, but a rational business decision is based on cost vs. benefit. It's a lot more difficult to estimate the likely cost of bugs (in terms of customer goodwill and so on) and of maintenance effort than it is to estimate the cost of writing code, so in the absence of information the rational thing to do is de-emphasise it. They need your help to make a better estimate of the likely cost of neglecting quality.
Dec
5
comment How do you balance between “do it right” and “do it ASAP” in your daily work?
"Often the sales team gets us into trouble just to get a commission" - At what point would you consider that sales should be held responsible for selling something that the business can't deliver - assuming there is one? Do you have examples where they've crossed the line between aggressive marketing and overselling?
Dec
4
comment How do I prove or disprove “god” objects are wrong?
The lead developer/manager/whatever should absolutely take all reasonable measures to ensure that the team retain a good working relationship with one another. If additional training is helpful, then by all means consider it as an option - but this seems to be like a case of wilful ignorance, and telling someone they need to be trained to understand your idea when what they think they've done is disagree, rather than not understand, could backfire. I have a hard time imagining ways of dealing with people who don't want to learn.
Dec
2
comment How do I prove or disprove “god” objects are wrong?
The manager's decision has been adequately justified, and if the team don't agree, then the problem is with the team. The OP was hired for his expertise and not being allowed to use it to benefit the business because colleagues won't behave reasonably isn't acceptable. Let's turn your assertion on its head - why shouldn't the resistant team members quit if their view of the job is incompatible with that of the business?
May
29
comment Dependency injection: How to sell it
It's often occurred to me that to really grok an ivory-tower concept like DI, you have to have gone through the same process as the evangelists did to realise that there was a problem to solve in the first place. Authors often forget this. Stick with low-level pattern language and the need for a container may (or may not) emerge as a consequence.
Mar
29
comment How to deal with tautology in comments?
Useful alternative that demonstrates how to turn a poor comment into a good one: // This is an adjective, not a verb. Provided for consumers that need to retrieve the update location because [x]
Mar
29
comment Adding complexity to remove duplicate code
This isn't really an answer, more of an observation: If you can't easily explain what a factored-out base class does, it might be best not to have one. Another way of looking at it is (I assume you are familiar with SOLID?) 'does any likely consumer of this functionality require Liskov substitution'? If there is no likely business case for a generalised consumer of interpolation functionality, a base class is of no value.
Nov
6
comment Why can't we get anything done?
That's what I've been trying to communicate for some time. As it happens, the prototypes are often valuable and do teach us essential lessons about the nature of the problem. However, whether or not those lessons are learned are left to chance, and the quality of the implementation relies on the developer reconstituting the acquired knowledge from their brain, rather than using the prototype to write the spec. The lead dev says the latter should happen, then doesn't follow through on ensuring that it does.
Nov
6
comment Why can't we get anything done?
Quite right. Unfortunately you may be obliging me to admit something that I didn't want to - that we have a lack of competence. It's evident generally, but particularly with the modellers. For some aspects we do insist on firm specifications, then it still ends up wrong. They're scientists, and speaking from experience, scientists tend to treat code like an experiment - correct errors as you go along. For the business this simply isn't good enough and it's a matter of professionalism to be expected to recognise this.
Nov
6
comment Why can't we get anything done?
To continue; Iterative development is the name of the game, you've got that right. Trouble is, the iteration peters out before it's actually finished because we get vague platitudes from the modellers about whether or not what we've coded is really correct. Nobody can identify any errors, so what we've done ships. Six months later it turns out to be wrong. I'd like to be able to point out that the modellers need to be given firmer criteria to test against, but then again, isn't it their job to say so?
Nov
6
comment Why can't we get anything done?
@Robert Harvey - It's difficult for me to judge. The products are extremely niche, and we (developers) get mixed messages. On the one side, new customers in breakthrough markets are thrashing the product more than we originally envisaged and finding faults as a consequence, which they don't seem to mind since we explain why and fix them quickly. On the other hand, some large institutional customers are distrustful and we're starting to take flak for repeatedly amending the model. The software team is one of the few breaking even in the company at present, so we look good at the moment.
Oct
13
comment How would you decline to have your name put on a software patent?
Somebody has missed the point of my answer, even though I made it quite clear. I was voicing what I perceive to be the opinion of patent lawyers and advocates of the patent system.
Sep
22
comment Is OOP hard because it is not natural?
@zvrba: My answer to the question posed in the comment is that it doesn't matter. Everything that has a name and a surname is a person to every program that only cares about people. For any program that has no knowledge of people or non-people, it's an IHasNameAndSurname. Objects only need to solve the problem at hand.
Sep
22
comment How baby are your baby-steps in TDD?
Marked as a Good Question for stimulating debate.
Aug
20
comment Why are data structures so important in interviews?
I'm going to present an opinion here that's likely to be controversial. The question of why one data structure or another tends to be down to efficiency and performance. What do we tell developers not to do? No optimising prematurely! Unless you know by profiling that the choice of data structure is causing performance problems, the 'right' one to pick is the one you're most familiar with. Any other decision is premature optimisation, and therefore evil!