Reply to: Good contract, bad tech - what to do?

[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.

[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.

[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.

[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.

[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.

[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.

[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.

[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).

[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.

[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]

I see your point my my issue here is that most contacts out there demand god experience developing in an Agile environment. I will be competing with these people come next contract. It wouldn't take long for a good interviewer to see my latest Agile experience is found wanting. I suppose I can just emphasise my previous Agile experience.

I wouldn't be too fussed about interviewers asking AGILE questions. Unless the interviewer is only interested in AGILE instead of your tech capabilities, I would not worry about it too much. I had a very quirky interview recently where I was drilled on AGILE only, but then again, I would not want to work in a place where they base their project on propaganda and hogwash. End of the day, a capable manager working with capable developers/contractors/testers should be able to get the job done without relying on FR(AGILE). And I am saying this after working with AGILE projects for at least 3 years. I must say, that all AGILE scrum masters I have worked with talk a lot (personal life, or how the boss is giving them tulip, in front of everyone etc), and are absolutely interchangeable.

[jmo21]

Interesting that the OP sees Agile as a positive. From a senior PM / Architect position its an absolute nightmare working in an Agile environment in my line of work. Fine for web sites and modular coding etc. where you can genuinely chunk things into tasks that take less than 4 days, but for a decent size design, forget it.

From my experience Agile = little design / no testing

If places aren't doing testing, it's because they don't employ tester resources.

Or they do, but outsource it, bob doesn't understand what is happening, says yes to everything on conference calls, and then it all falls arse over tit on go live.

[TheFaQQer]

Everybody has their own idea of what Agile means anyway, so just learn to BS your way through and you'll be fine.

If I was in your position I'd be pleased I had a year's work at a decent rate.

This

[TheFaQQer]

Can contracts even be broken early?

Contracts can ALWAYS be broken.

Whether your contract can be terminated early legitimately, is a matter for you to determine based on what the contract says.

[CoolCat]

"Agile" is a load of bollocks anyways isnt it. Mostly projects using "Agile the methodology" are not "Agile the common meaning of the word". I have seen countless big Agile projects go belly up for blooming obvious reasons. This industry is so full of quack medicine for it ailments and so full of tulip leadership.

Arghhhhhhhhh