links for 2010-04-30

  • Facebook
  • Twitter
  • Delicious
  • LinkedIn
  • StumbleUpon
  • Email
  • RSS
  • Reddit

How not to implement Agile…

  • Facebook
  • Twitter
  • Delicious
  • LinkedIn
  • StumbleUpon
  • Email
  • RSS
  • Reddit

I read a very very interesting blog today: http://blog.objectmentor.com/articles/2010/04/23/the-tricky-bit

In short – it describes what happens when a development team get Agile really right. Consistent releases, adding lots of business value, working normal hours, creating calm from chaos. Brilliant. However, this can induce a certain amount of suspicion in managers as they think you’re not working hard enough compared to the chaotic teams that are always creating delays, working all nighters, making a song and dance and then fixing it a bit. Quite often these teams have lots of “senior developers” who write some lovely gumph that is ugly and inefficient to fix a problem that should never have arisen. These developers are nearly always congratulated and given lots of kudos as they are at the forefront of manager’s attention for being, well a bit naff to have to work 12 hours a day in the first place….

So onto my actual reason for this “blant” (blog rant) is that I see it in most companies where the efficient, clever developer is waylaid for lovely, simple solutions (the crux of agile in development) for chaos. Fair? I think not. Managers really do need to grasp the point of Agile as well as the developers (well some anyway) do. Simplicity is key. It was also pointed out to me today that because Agile is actually really simple and about making other things simple, it must be really hard to have enough to be an “Agile Trainer”. We decided that they actually add loads of corporate gumph that is detrimental to the process in order to “train” companies in Agile development. Isn’t that a bit daft?

This can quite often mean that your developers who are great get forgotten about for promotion and payrises that quite frankly, they deserve thanks to chaotic developers working like maniacs hacking away at things instead of simplifying the problem effectively. This can’t be the best way for business???

The art of listening to your Developers and how to approach them.

  • Facebook
  • Twitter
  • Delicious
  • LinkedIn
  • StumbleUpon
  • Email
  • RSS
  • Reddit

You would think that this is an easy peasy thing to master. It all seems a very simple task to undertake. Simply, have an idea, tell the developers your idea, they make it, simples. Unfortunately this is all too much the case. I myself have been a developer for what seems like 40 years but is actually only four and I have too often come across people who ask developers questions only to in fact go through the motions and pretty much ignore any input they give entirely.

There are different types of person who may require input from developers and the stunts they pull to make our lives harder:

1. The Project Manager.
A project manager has the difficult task of coordinating projects throughout their life cycle and making sure that all parties provide their bits of a project on time and to make sure that everyone has what they need. Not a job I think I’d like to do for a living as is often the case, you can’t please everyone. I have come up against several types of Project Manager in my time and have found varying levels of annoyance with most of them apart from the Project Manager I once had who said “Kirstie, in your honest opinion, how long are you going to take to complete this?” I gave an honest answer factoring in time on other projects and the odd 10 minutes on lolcats here and there. He nodded his head and said cool fair enough and told the client – “this is when it will be ready” and added on a week for me to cock something up and spend 2 days fixing it. Perfect. However, this has happened exactly once in my life and the rest of the time I’ve been met with several rubbish statements such as “excuse me, I can code HTML you know – I KNOW how long things take and there is no need for you to spend that long changing something” never mind the fact that I code PHP and avoid front end where I can. So what did she do? Ignored my advice and gave me 3 days to do a 2 week job. I took 2 weeks and told her why every 5 minutes when she asked why it was delayed. She sucked. You also get the project managers who when faced with a rather demanding client will give a time estimate based on pure fiction and not even ask the developer in the first place! “Kirstie, I’ve said you will provide this in 3 days ok?”. Not ok! It’s about 3 weeks worth of work are you insane! Ask me next time as I am NOT going to appreciate the all nighters I’m about to pull to save your behind! He sucked too.

2. The Development Manager.
I’ve had awesome dev managers and some really sucky ones in the past. The awesome ones knew that you were there to not only do your job as a developer but also to help you to really plan and manage development tasks effectively. Most development managers are seasoned developers themselves so quite often you get them on your side saying to the Project Managers (see above) that they are in fact living in Star Trek and this is the real world. Sometimes though you can get some development managers who really gave up programming because they couldn’t be bothered to keep up or be any good anymore. These ones were hackers in the last bits of their development lives and therefore expect you to be willing to hack away at your lovely code as well. These ones can be harder to get off your case as they do have a bit of knowledge and you have to really give a good reason as to why you’re not going to be a rubbish developer at that time. We all know that hacks are bad and that if we are asked in the first place how something needs to be written – we probably wouldn’t have had to consider nasty hacks in the first place.

3. The CEO.
Quite often you get a CEO who is super super interested in development projects on a rather real level. The ones who just want things done and can be talked round to your way of thinking are brilliant as long as you don’t let them intimidate you, but the ones who perhaps once programmed a bit back in the 80s before they decided they’d rather let other people do that and take all the credit for it can be very dangerous. They are the people that will promise other CEOs things that they have no idea whether it is possible or not and assume that anything is possible if he says it is. This can lead to lots and lots and LOTS of late nights and fretting because your jobs usually are running on hairbrained schemes and you probably spend your evenings on jobserve…… don’t blame you. I did.

4. The Micro Manager.
I will make no bones about it. I HATE micromanagement. I mean I really really loathe it. How on earth can you get any kind of productivity going if you’re constantly being watched, asked if it’s done yet, and being told “that’s not right, the document says this.” Well if you gave me the document, I might know what I’m doing! If you don’t let people do their jobs, they very often won’t be able to do it at all and therein lies a big big failing. Micromanagers usually always expect you to go hell to leather for 8 hours while you’re at work and expect you to eat your lunch while working – so no lunch hour there then! I personally after an hour or two’s really hard work, need a bit of respite. Usually in the form of lolcats or buzzfeed to give my brain a bit of break. Do not do this with Micro Managers, they will assume that you spend most of your day slacking off and take you into a meeting room where you will have to explain what you have done every minute for the last 4 hours. Rubbish. These people never listen to developers until it’s too late and they’ve found new jobs.

It is my firm belief that there are two types of developer as well:

1. The Constant Developer.
These developers will keep plodding on all day to get to a solution and think through things as they create some awful code and refactor it as they go along. They steadily plough through things and generally are the ones that you never find on facebook/twitter/lolcats through the day at any time. These types of developers are great for bug queues. They will fix loads and loads of bugs in one day without worrying about getting bored and will very rarely be looking for better ways to solve a problem other than what they’ve encountered in the last 2 years before they got bored. You may completely disagree with me on this but it’s my observation over the years. You can usually tell a constant developer that you’ve completely underestimated a task and they will just keep going till it’s done without worrying too much and probably will come up with a middle of the road solution that will please everyone for now.

2. The Burst Developer.
This is definitely me and I like it. Quite often burst programmers will do the same amount of tasks as a constant developer but they are very different in their approach. If you tell them you’ve underestimated a task, they will get rather irked at you for several reasons. a. They can’t spend time thinking up a solution that really is appropriate and will have to just hash it together at the time. b. You are taking away that “thinking while reading my facebook” time which is very important when you’ve been going at it for the last 2 hours. Burst programmers once they have the idea they want will go at breakneck speeds to do what it is they have thought of. This is much much faster than a constant developer and will quite often get done in 5 hours what a constant will do in 2 days. Burst developers tend to be more innovative by nature as they spend a lot of time thinking of the best solutions to problems which includes doing some research before setting down to it to see if there’s anything they can use/steal/borrow to get it done more effectively. If you really really need to tell them that they’ve got to do too much work in too little time, I suggest approaching them with bribes such as Starbucks and cake. You may not get a lecture that way…. This is not to say we’re all completely moody (I was prior to allergy monitoring but have calmed down a lot) but it is disappointing when your peers don’t respect your opinion enough to make sure that everyone can do the job they do without people thinking they know everything while making a right royal mess.

All in all, I think it’s important to always keep your developers in the loop no matter who you are or what type of developer you have. Without their input, you will not have a full picture and then everyone’s miserable instead of on the same page and being set up to succeed.

if ($developer == ‘:D’) { $productivity++; }

  • Facebook
  • Twitter
  • Delicious
  • LinkedIn
  • StumbleUpon
  • Email
  • RSS
  • Reddit

Just in case you don’t get the title, what I’m trying to explain is how to improve productivity in employees and especially geared towards us developers. It’s quite simple really as it involves making sure people are happy in their work and working environment.

I came across a blog that stipulated “nine things developers want more than money” which really goes through it well including innovation, few legacy constraints, not a squillion meetings to change anything in a project, having a voice in your work, being appreciated for what you do, good management (I agree, micromanagers annoy the hell out of me), doing work that matters and one of the most important ones: being set up to succeed. A lot of the time, you are not. The blog is here: http://www.softwarebyrob.com/2006/10/31/nine-things-developers-want-more-than-money/

But to add to that, I think it’s really important that developers can be themselves in their job. Considering the extraordinary amount of extra work software developers usually do, I think a degree of flexibility is key. I also think that a company should place quite a bit of focus on the type of people they want to hire. For example, I’m usually (believe it or not) outgoing and really like a sociable atmosphere and I think like minded people work well together rather than just banging on about skills alone.

So I guess my point is it’s not all about loads of money, quality of your environment and work is also really important.

To MVC or not to MVC….

  • Facebook
  • Twitter
  • Delicious
  • LinkedIn
  • StumbleUpon
  • Email
  • RSS
  • Reddit

I would put money on most programmers these days having at least heard of the architectural pattern “MVC” (Model View Controller) and I expect many have used it or been involved in projects which claim to implement said pattern.

MVC in short is a typical hierarchical pattern which allows lots and lots and LOTS of objects to be split up into a. a model: this in short is the actual object within a package which is usually used to represent a table in a database somewhere. It handles all the prep work needed to store, modify and delete an object from somewhere. B. is a view. The view itself is what the end user actually sees. The only logic in here should be things like looping through a collection of objects to display. C. (quite aptly) is a controller. This does exactly what it says on the tin and controls the object and how it is presented to the view and also does the “doing” of things that the view tells it to do.

“How very simple!” I hear you cry! “I am SO going to use that – amazing!” I hear you exclaim.

It is exactly that IF and this is a very big if, IF it is actually appropriate.

Please be reminded that this is, my most humble opinion and I would not dream of depriving you of your controllers with data calls in or your models that logs a user in for you… unless you want me to work on it in which case, buck up your ideas sunshine.

A very appropriate example I did just happen to mention there. In object oriented programming, you have to be very careful not to fall into the trap of “I use objects because I can reuse the code in them”. This I think a lot of programmers are guilty of thinking like whether they would care to admit it or not. What that is my friends, is a library. A library is a collection of reusable objects and code. Object oriented programming in itself runs much much deeper than that. In order to explain this fully, I direct you to something that I heard in my first ever lecture on Object Oriented Analysis and Design. Objects are nouns, inside the object we have properties, we set and get those properties in that object. That was it, that’s an object in very simplistic terms. As commercial programmers, we are driven by bosses bending our ears about timelines, deadlines, overdue promises (and today I was told you do this to time even though a week was wasted because you were the only one in the office without any specifications – jobs will be lost.) which in turn can make us a tad sloppy when under pressure if we haven’t had the time to really plan out our work properly. This can be a time where you find action work creeping into our lovely defined objects which should really be abstracted away as perhaps a helper object or a service object.

Due to the sheer size of some MVC projects, we can have exactly that. A lot of rushed projects in one big MVC structure with lots and lots of hacky implementations of something that resembles MVC. This to me, is a reason to reconsider your architecture…..

Although I’m not biased towards SOA, I do really appreciate the freedom of design for a system that it provides. For example, in your standard e-commerce app you would have:

Display

User Management

Product Management

Stock Management

Warehouse integration

3rd Party integration (suppliers and whatnot)

Order Management

Payment Gateways

The list expands and contracts depending on requirements obviously but we can safely assume that a lot of those things will be in even a small e-commerce project.

Now say for example that a user has lots of properties, the project also has lots of different types of user. You need to establish what user is what and use the properties accordingly throughout the system. You also have a mobile app that needs to use the same code without all the web based gubbings. In a normal MVC structure – you would use the same bootstrap file to access the whole project and change your views.

OR, just an idea: You could have a component, loosely coupled to other components with a lovely interface that you could just go “Dude, I need the properties for that user” or “Righto chaps, time to change this user’s email address.” Or something overly complex like “Ok mate, I need a full list of users’ email addresses and permissions to do this manic thing with emails” Ok that wasn’t that complicated, I apologise. However, The last example is a good one: I do not want to have to go into my massive huge application to get a list of user email addresses. Neither do I want to have a big application that I have to rewrite loads of stuff so I DON’T have to do that. By having my user management componenent I can do exactly “Ok mate, need a list of stuffs – gimme” (this is how code should be hehe) also since everything goes through my interface, my code is protected from hacky developers going “need this thing, going to go into the model and just do my action – simples”…. Don’t do that George, it’s not nice.

The benefits of having loosely coupled components other than the ones I’ve mentioned include the difference in actual code usage and implementation risk levels.

By having a component that represents a service or application, you are abstracting your code for this project away from the major enormous project as a whole, this means that your api implementation is lower risk as you only have to worry about the conversation between apis rather than lots and lots of reverse engineering to find those params you got the wrong way round during injection…

A lot of people might say – but dude, I may want to use that XML converter object in another component! Yes you might, that’s why I’m also a huge advocate of libraries… Whack it in there. Or even better, use something like Zend Framework (minus the MVC stuff) and just use that. In a lot of places, I’ve had a core library for stuff that is needed in multiple components and Zend Framework library for stuff that I really don’t want to write again – I’m pretty sure those people had much more time to write that and it’ll be a much better implementation of it since I’m so stressed writing projects in time for silly bosses……

MVC was ditched by Java for a reason: I hope this helps to begin to explain why!