9

I work on a small team, in a medium-sized company, most of which isn't involved in software development. I'm the newest and least-experienced developer and had no professional or academic background in software before starting, but I'm quite pleased with how respected my input is and am grateful for being taken seriously at such an early stage in my career.

Still, I feel like I should be doing more with this generous amount of airtime. As a team, we seem to have trouble getting things done. I'd like to be able to suggest something to improve the situation, and I think I'd be listened to if it was a good idea, but I'm at a loss for what to suggest.

Things I can identify as being issues include:

  • Specification of the tasks at hand is sparse. This is partly because management is a bottleneck and we don't have the money or people to commit to working out detailed requirements as much as we'd like. It's also partly because the software we're developing is investigative and the precise method isn't clear until it's demonstrated and used to determine its effectiveness.
  • The Lead Dev is very fond of what he calls 'prototyping' to the point that he's lately started insisting that everything is 'prototyped', which to the rest of us looks like writing bad code and giving it to the modellers to play with. It isn't clear what he expects to come out of this exercise in many cases. The 'actual' implementation then suffers because of his insistence that good practice takes too much time from the prototyping. I haven't even begun to be able to untangle this twisted logic and I'm not sure I want to try.
  • The modellers are expected to tell us everything about the desired methodology in precise detail, and it's taken on absolute trust that what they come out with is theoretically flawless. This is hardly ever true, but no action is taken to rectify this situation. Nobody on the modelling side raises any concerns in a structured way that is likely to be acted upon, nor do they seek guidance in applying best practices. Nothing is done about their passivity either.
  • I've tried to push TDD in the team before, but found it difficult as it's new to me and while those with oversight of my work were willing to tolerate it, no enthusiasm has been forthcoming from anyone else. I can't justify the amount of time I spend wallowing and not finishing features, so the idea has - for the moment - been abandoned. I'm concerned it won't be picked up again, because nobody likes to be told how to do their job.
  • We now have a continuous integration server, but it's mostly only being used to run multiple-hour regression tests. It's been left open that it ought to be running full-coverage unit and integration tests as well, but at the moment nobody writes them.
  • Every time I raise the issue of quality with the lead dev, I get an answer to the effect of 'Testing feature A is straightforward, feature B is much more important to the user but too difficult to test, therefore we shouldn't test feature A'. Once again I've made no headway in trying to untangle this logic.

....phew. When I phrase it like that, it looks much worse than I thought. I suppose, as it turns out, this is a cry for help.

Improve this question
4
  • 5
    How good is the company at pushing out software that the customer uses and likes? In other words, is the team getting good results, in spite of the fact that you do not believe the process is stellar?
    – Robert Harvey
    Nov 6, 2011 at 17:58
  • @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.
    – Tom W
    Nov 6, 2011 at 18:04
  • 1
    I would solicit as much feedback as you can from the customers for ways to agree on a basic working "model," and try and solidify that a bit. It can indeed be frustrating to customers for a model to change, but if this is new, cutting edge software, it goes with the territory.
    – Robert Harvey
    Nov 6, 2011 at 18:17
  • Good question. I've noticed that even with a receptive audience, real change is hard, unless you can see it working in practice. My advice is to try approaches to increasing your productivity first, and then demonstrate these for the team. With practice, you can get faster at TDD development than write/debug/repeat.
    – Mike B
    Dec 12, 2011 at 15:39

4 Answers 4

Reset to default
19

Let me play devil's advocate for a moment:

Specification of the tasks at hand is sparse... The Lead Dev is very fond of what he calls 'prototyping'

The lead dev is fond of prototyping because specifications are sparse. This is probably a good thing; this is how iterative shops work.

The modellers are expected to tell us everything about the desired methodology in precise detail

This won't work in an iterative shop. The very nature of iterative development is that requirements are often incomplete. The iterations are what is needed to flesh out the requirements.

I've tried to push TDD in the team before, but found it difficult as it's new to me

This won't work either; you need to understand the technology before you can evangelize it. Further, in an iterative shop with scant requirements, TDD may be too much overhead. It's better to encourage adequate unit testing coverage.

We now have a continuous integration server, but it's mostly only being used to run multiple-hour regression tests.

That may be appropriate in a small, iterative shop.

Every time I raise the issue of quality with the lead dev, I get an answer to the effect of 'Testing feature A is straightforward, feature B is much more important to the user but too difficult to test, therefore we shouldn't test feature A'

It sounds like your shop has some fairly tight time constraints; like it or not, you are bound by those constraints.

It also sounds like you came from a part of the software industry that values doing things "the right way" over getting things to the market first. There's nothing wrong with that (it's admirable, in fact), except that the first to market with a buggy piece of software is often the winner. It's not fair, but that's how it is.

Improve this answer
5
  • I think you are going to need to approach it from a "technical debt" perspective. Every company does time estimates; assuming yours are pretty good already, start building a 10% to 20% surplus into your time estimates for refactoring and training, and make it stick.
    – Robert Harvey
    Nov 6, 2011 at 18:14
  • 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?
    – Tom W
    Nov 6, 2011 at 18:15
  • 2
    @Tom: As long as you don't insist on testable specifications from the modellers, they can always tell your team that they got it wrong. If they're going to hold you accountable for producing results from their model, you've got to hold them accountable for providing you with testable specifications so that you can declare success. Every specification should have built into it some sort of "go, no go" test, so that you and the customer (or the modellers) can mutually agree that the test passed, without being subject to interpretation.
    – Robert Harvey
    Nov 6, 2011 at 18:20
  • 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.
    – Tom W
    Nov 6, 2011 at 18:39
  • There's nothing wrong with treating code like an experiment; that's part of the iterative process. But eventually you have to get around to "this code accepts these inputs and is expected to produce this output." That's what unit tests are for; they form part of the specification. I can see why you want to do TDD; it forces specifications onto the code... But you need support from the corporate culture to make that work, and TDD has an air of "religion" about it. Not everything is testable this way, so in the end, you may have to live with a certain degree of discomfort.
    – Robert Harvey
    Nov 6, 2011 at 18:45
2

I'm going to focus on the prototyping here

the major issue with prototypes is that they are meant as proof of concept

however if you can't build further on the prototype and need to rebuild the final product from scratch you might as well not have build the prototype and you have wasted your time building it

my advise to your team is to get some quality and flexibility in those prototypes. I know it's not possible to create perfect stuff first time but try to remain extensible for future requirements

Improve this answer
3
  • 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.
    – Tom W
    Nov 6, 2011 at 20:09
  • when he says he wants a prototype what he means is he wants a minimal working version, and as fast as possible. This will be the foundation for the final version. The problem with the approach is that junior devs (generally) can write either good code, or can write code fast, but rarely can do both at the same time.
    – Kevin
    Nov 6, 2011 at 21:04
  • 2
    Fred Brooks said "Write one to throw away, you will anyway", that's as true today as it was 40 years ago.
    – mattnz
    Nov 6, 2011 at 23:14
1

These are good answers. I can only add that "trying to communicate" is at best an iffy proposition. Changes in the way an organization works do not come about quickly. When it happens it's often like a tide, where momentum builds from below and from above. So you'll be happier if you keep your expectations low and either wait for your chance to say how things will be done or look forward to working with another organization.

Improve this answer
1

Have you identified someone at the company who "gets it" if so, latch on to this guy and learn as much as possible from him. If not, bide your time, start learning and growing on your own (join an Open Source project or start up your own project), and look for a place that can foster your growth.

The worst thing that can happen is you stay there and learn how to do things the wrong way. Yes, there should be some pragmatism taken, but a truly skilled team can do things the right way and still be on time with a quality product. It sounds like your current team does not have what it takes and you should start looking for a new one.

Improve this answer
1
  • "Have you identified someone at the company who "gets it"" LOL
    – Kenzo
    Dec 5, 2012 at 20:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.