The Hacker mentality in development

8 11 2012

There is a lot to be said for hackers, many of them are, well quite simply, brilliant with computers and poses some great knowledge. I’m not approving of what they do, as I think those actions are disgraceful and show a blatant disregard for the law, privacy and peoples livelihoods. However, many companies build their software with a hacker mentality, which is “get on and do it, make it work” kind of thinking….Lots of doing, little planning….I can’t think of anything positive to be said about having a “hacker mentality” when developing a piece of software or a platform. Such a mentality is ok for building proof of concept parts of software, you simple cobble together a rough solution that shows the concept and you use it to overcome / address some technical difficulties you may see in the future. However, take that mentality and approach into the actual project and it’s only a matter of time before something comes back to bite you…

 

Facebook

Facebook is the biggest and most obvious example I can think of. The platform and social network is brilliant in many ways. However, spend much time trying to use it for business, for managing ads, campaigns etc and you get the feeling that everything really is “cobbled” together in true hacker mentality fashion. Things just don’t seem to play well or consistently and you seem hamstrung by so many restrictions which have been basically caused by not enough forward planning, rather developers just doing…You really do feel like the platform was built for its one role, and that everything else is almost stand alone trying to be bolted to the UI.

In recent weeks I have watched a digital marketing agency wrestle with Facebook in order to get it to behave how it really should. It’s not the agencies fault, far from it, once they managed to get someone from Facebook to talk too; it became apparent that most of the staff at Facebook are aware of the amount of bugs in the system and the restrictions that are in play. For me, the whole experience is at best “proof of concept” and essentially shows that there has been a real lack of forward planning. Facebook is a company though that was founded largely on “doing” rather than planning…

 

Don’t get me wrong, there are some impressive concepts with Facebook and many parts of it are implemented very well, but you cannot get away from the fact that anything outside its original core feels like its been added on as very much an afterthought and that its very “prototype” in terms of feel and implementation.

 

Technical Architecture

I’m not going to bang on about the right way to do things, rather just to say that any development project really needs certain key roles, and the biggest two are ETA (Enterprise Technical Architect) and TA (Technical Architect). These roles don’t fit in with the hacker mentality at all. If you have two people who fill these roles, and do their jobs well, you will find that as a project grows and new requirements come on board, that they can be added to the system in quite an efficient way. Tested separately and rolled out smoothly. The new additions become seamlessly part of the software and things don’t feel cobbled together and they don’t feel like prototype or beta software. Why? Well because these people plan for the unexpected, they see the bigger picture and look at what potentially one day may also be required from any given part of software. If you plan your system like that, when new requirements do come along, you can build them into the overall solution without causing any “jarring” effects within the software or for the user.

Having people who ensure you plan all components for the future keeps longer term costs down, and delivers software that can truly grow with your business. There is nothing worse than having to go back and re-engineer code because it was implemented with only that one function / requirement in mind…

 

Adaptive, SCRUM, RAD…

There will always be a better way to run your IT projects. New methods for ensuring you get code developed quickly, built to specification and future proofed. However, without having people who think ahead at an enterprise level (regarding technology, architecture etc) or people actually ensuring developers do the same, then no matter your methodology, changes further down the line won’t be easy, rather they will be quite troublesome, slow to implement and often result in a cobbled together field, ala Facebook ads management…

You simply can’t beat people who forward think…





Why IT projects fail

8 09 2010

In my previous post I looked at “How do we ensure a BPM project succeeds”, but it got me thinking, why do many IT projects fail? I racked my brains through the very few projects I have been involved with directly that have, not failed as such, but not gone well shall we say. I also started to think back to many projects I was brought in on to help succeed, and tried to remember just why they were failing in the first place.

There are numerous reasons why projects fail, why requirements were missed, why over complex procedures are put in place when not needed etc etc. But what are the real big reasons, what do we have to really understand and monitor closely as to keep an eye on proceedings and limit the chances of failure…

Politics

Ahh internal politics. This is possible the biggest singular reason why projects fail, usually as a direct cause. So what do I mean here…Well, at the early stages of a project, you need to ensure you get the right people with the right knowledge involved, especially if you are identifying requirements. But this is where it all starts. Straight away politics takes over, and putting together a “high level” team, along with “senior users” etc all means politics kicks off. For example how often are you working in a team and realise (as a consultant) that some of the people in that team from the company just shouldn’t be there. Why are they there? In addition, you walk the floor and find key users with a lot of knowledge not involved in decision making? Their absence has meant functions are overlooked, processes missed and for what reason? Often it is internal politics that decides who is in what team…

This isn’t the end though. No, internal politics can also mean you see key personnel dropping out of projects being moved elsewhere in the company. You also find people trying to make a name for themselves using your project as a vehicle, and because of this they slow everything down, re-visit old ground and basically make everything a pain in the neck (being polite).

My favourite experience though is internal IT departments refusing to get involved because they were not consulted with at the beginning of a project. Classic….There are so many many more examples, but let’s just say, if a project is going to fail; internal Politics will have something to do with it…

Before moving on, internal politics can also lead to the wrong system, solution or vendor / consultancy being used. More often than not, internal politics determines just who the business can work with on a project, not even taking into consideration expertise, skills, price and many other common factors.

Nepotism

This follows on from politics to be honest, or could even be seen as a part of internal politics. Unfortunately nepotism can often raise its head on an IT project. In many cases (well all in my experience) this causes friction and can have a real negative impact on a project, contributing to failure ultimately (if it goes that far).

It sounds obvious, but if someone just can’t pull their weight, or doesn’t have the necessary knowledge to be involved in the project (no matter what stage) then that person, no matter who they are, shouldn’t be involved….

Building on this though, it can also lead to particular vendors, or particular firms being used when simply they shouldn’t…

Incompetence

This one is a worry, as how do you identify someone is incompetent before it is too late? Unfortunately I have worked on projects with people who just don’t have a clue. To say they are incompetent maybe an understatement. I, as a co-worker can spot this, but more often than not, manager’s spot incompetence too late. It is therefore important that managers get a feel for their team, get feedback and try to judge if anyone is being “carried” or just plainly is incompetent

Change Management, or resistance to change

This one is deadly; it seems to creep up on IT projects. The 3 reasons before can all be “nipped in the bud” with good management. In addition they show up early in an IT projects lifecycle. However, poor change management or resistance to change from staff can mean that you may have the best solution in the world, but it will ultimately fail because no one wants to change the way they work.

To minimise this, IT project managers need to get not just key staff involved early on, but as many staff members as possible. I am not suggesting they all get to put their 2cents in, but allow them to feel a part of the project, get them involved in reviews, prototypes, demonstrations, the odd focus group etc. This way ensures that when the system comes along, many users have already come to terms with this fact and the solution itself. It minimises the risk of change resistance…

Conclusion

Ultimately managers make or break a project. The reasons shown above can all be avoided with good business management, good people management and a little dash of political prowess.








Follow

Get every new post delivered to your Inbox.

Join 864 other followers