Good contract, bad tech - what to do?

[doodab]

From my experience Agile = little design / no testing

That is part of the problem. People use it as an excuse for not bothering to manage. IMO being "agile" isn't about scrums and sprints and a bulltulip PM methodology so much as it's about technical decisions that take into account the need to create easily testable, well modularised code for the long term health of the project. You can plan your project and delivery schedule however you like if you take on board modern architectural, design & day to day working practices that result in quality code.

e.g where I am code is now designed & written with thought given to automated unit testing, IoC helps with this, sometimes tests are written first when we're exploring, code is automatically checked out, built, and unit tests are run several times a day, errors are flagged up or the latest code is automatically deployed to a server where integration tests can be run, manually but we are looking at automating that now. Only once we have 100% pass rate on the automated tests do we give anything to the testers.

We aren't "agile" or "scrum" or anything else, we have a huge upfront project plan and a two year roadmap. This is just stuff I have pushed for since I came in. Before that every dev had their own private copy of the code running on their own machines and it took them 3-4 weeks to get code merged. Testing, which was more like basic debugging, was done in the runtime environment with no prior verification of the moving parts. It had never actually been deployed to an actual server. Sorting it out was more to do with preserving my sanity than my career. Oddly after a bit of resistance all of the other devs have been very receptive to the changes because it's made their lives easier, they get more done more quickly and they are starting to enjoy themselves a bit more.

So, in answer to the OP, try and lead them where you want to go, you don't (or shouldn't) have to be in charge to make suggestions that improve working practices and code quality, and if you drag them into the light that will look as good on your CV as anything.

[tranceporter]

e.g where I am code is now designed & written with thought given to automated unit testing, IoC helps with this, sometimes tests are written first when we're exploring, code is automatically checked out, built, and unit tests are run several times a day, errors are flagged up or the latest code is automatically deployed to a server where integration tests can be run, manually but we are looking at automating that now. Only once we have 100% pass rate on the automated tests do we give anything to the testers.

That's some quality stuff right there. That is how modern software should be written. Proper people being hired to do proper jobs with proper process in place. Not many organizations achieve that.

[heyya99]

The lack of Agile is only one part of the problem. I am working in Grails. Had to learn from scratch.

Positive: learn new language.
Negative: Not increasing knowledge of Spring and Hibernate ( because both are done 'under the hood' of Grails).

[DigitalUser]

The lack of Agile is only one part of the problem. I am working in Grails. Had to learn from scratch.

Positive: learn new language.
Negative: Not increasing knowledge of Spring and Hibernate ( because both are done 'under the hood' of Grails).

Each contract is what you make of it. If you feel the team could use practices derived from things like Kanban, Lean and Scrum then go ahead and do it; the worst thing that'll happen is that people will say no. Explaining 'why' instead of 'how' also makes a massive difference - people buy into things if they understand why they may work.

I wouldn't say process is the be-all and end-all (coming from a developer turned ScrumMaster) - as long as you suggest things that people can buy into, and do it in a way that doesn't p*ss people off, then that's something you can take to future roles. The alternative is to leave things as they are, but given your current twitchiness, look at this as an opportunity to make things better.

[SueEllen]

The lack of Agile is only one part of the problem. I am working in Grails. Had to learn from scratch.

Positive: learn new language.
Negative: Not increasing knowledge of Spring and Hibernate ( because both are done 'under the hood' of Grails).

If you don't learn new skills then you will become like the guys who did desktop support - easy to outsource.

In this contract you have opportunities to learn both new technical skills and new soft skills.

[MyUserName]

At my client some of the technology is very old. I have made cases for updating it backed with a sound business case and hence I got to play with new techs.

If you can explain how it will help the client then tell them and push for it. If it will not help the client and will only help you then forget that and work on some open source projects using newer techs or just start them yourself.

[heyya99]

For software development, what time of year are generally the buoyant and slow markets? If I was to move, there's no point in moving in a slow market.

[TheFaQQer]

For software development, what time of year are generally the buoyant and slow markets? If I was to move, there's no point in moving in a slow market.

Every month is slow.

Or every month is buoyant.

Depends on your skills, experience and marketability - there is no such thing as the "market" which applies to everyone.

[SueEllen]

It depends on factors that include your skills, the industries you are willing to work in, the locations you are willing to work in and the minimum rate you will work for.

[MyUserName]

For software development, what time of year are generally the buoyant and slow markets? If I was to move, there's no point in moving in a slow market.

Market buoyancy is not just a single factor, it is like car insurance where there are dozens of different factors acting together to provide you with a customised and unique figure.