WRITE BUG FREE CODE OR WE'LL HIRE MORE PROFESSIONAL DEVELOPERS
Monday June 01, 2009
From the keyboard of   mark

It seems as if the business doesn't understand anything about software development. They believe the best thing to do is shut the door and six months later they'll open it and get exactly what they want. And we as technical staff understand that software is a complex beast that must be thought about, planned, architected, documented and implemented, while throughout the whole process there should be due-diligence, testing, peer review, etc.

So trying to explain this to the suits led to one of them getting very upset and blurting out, "Don't write anymore tests, if you can't write bug free code, then we'll fire you and hire more professional developers who can write bug free code". At this point i boiled with anger, but bit my tongue and let him look like an idiot.

So what can we do to show people like this, that being a professional developer means we write tests. Well it really depends on the person, some just don't want to understand, its easier to yell and scream and be on their way.

But for others, especially those that are money orientated, or can see the bigger long term picture, than what i've found explaining the cost of a single line of code, quantifying it, helping them understand that without testing, without planning that line of code could get changed three to four times.

Thats a lot of time to be rewriting existing functionality. So it can take three to four times as long to create / leverage the existing functionality for new improvements. Thats a lot of dollars when you think the average tests, planned line of code cost around $2-3 while untested, undocumented, unplanned is reaching towards the $5 - $7 mark. Ouch, thats a lot of wasted time, energy, and money.

If they still don't listen, chances are the project will die. I would jump from the sinking ship, into something a little more stable.

testing agile executive

WHAT AM I DOING HERE?
Thursday November 20, 2008
From the keyboard of   mark

I have to ask the question that rarely gets dignified by an answer. Why are we here? Now I don't mean why we're alive and on earth living day to day (although if you have the answer, by all means share it), but instead I'm wondering why I'm working for. What good am I doing? Could I do anything different to help improve the company I work for? All of these questions generally go unanswered by the powers to be.

So the owners, executive team and of course the managers spend so long focusing on the customer, the market and the bottom line that they tend to forget that all of these things don't make a great business. What makes a great business is the people. I hear often from the execs and managers "I can never find good people", my immediate response is, what makes a person great? I've had a mixed response of answers, which when thought about all seem to be the same. "I want employees that work hard, are motivated and don't complain", they say usual with a laugh.

I think everyone has the ability to be a hard working, dedicated and thoughtful employee if only given the chance. So the question is, how can we give them the chance? First of all a mission statement, and a vision for the company needs to be well thought out and written up on the wall for everyone to see every day. Once a goal has been written out you'll be surprised how dedicated even the least motivated staff can be.

Also, you need a way to improve morale. This I believe is best done with a documented set of values and culture. Let the team understand what type of people need to be working for you. Do you want a highly corporate environment like IBM or would you prefer a laid back place of work like Google? Both get things done, but you'll attract completely different people to each organization.

Make people feel wanted. Offer them excellent support, and let them know your happy with how they work. This doesn't have to be by remuneration but can be as simple as a pat on the back, and the acknowledgment that you see the good work they are doing. Don't be afraid to do something good for the body and soul as well. Biscuits, team, coffee, discounted gym memberships, lunch time walks, free fruit are a few suggestions, the sky is the limit, just remember a happy healthy body translates into a happy mind and soul.

executive

THE ARCHITECT
Tuesday July 08, 2008
From the keyboard of   mark

Like always I'll ask a question to get things started, what role does your architect play in the success in your company? Where I work at the moment sees the architect's role simply creating some target state architecture documents. Generally in powerpoint presentations.. On further investigation of his target state presentations it seems they were borrowed from flickr and you tube.

In my time I think I've met one architect that was a documentation machine, others along the way tend to produce very little in the way of artifacts and instead spend their time producing pretty power point presentations or "researching". In my opinion, instead of sitting above the developers I believe these guys should be one of them..

They should be involved in the code in a very intimate way. Maybe spending as much as 40% of their time with wrist deep building functionality. 20% of their time should be messing around with emerging technologies and the rest of their time should be researching and documenting findings.. All of these documents that are developer should be freely distributed to the development team and any one else who is interested.

To many architects tend to hord the information. How are the developers ever going to learn if nobody teaches them? You know you've found a good company when the developers are allowed time to research emerging technologies along side of the architects. So back to the original question, what role does your achitect play in the success in your company?

architect

IS AGILE JUST LIKE WATERFALL?
Thursday July 10, 2008
From the keyboard of   mark

Well is it? Well no its not, they still have some similarities, but the key differences between the two are:

Instead of just listing them, let me go through each of them and explain the difference between the classic waterfall and agile.

Communication over Documentation

This is the idea that reems and reems of documentation rarely gets read. Instead, only store the usefull bits of information in documentation. Its much easier to communicate verbally. The easiest way in my experience to communicate via documentation are things such as wiki's, emails or code based documentation. Of course this doesn't mean we don't write anything in word, that is stored for future reference. Instead we just look at spending more time building product rather than write about building.

Collabrative Team Driven Design

Traditionally in waterfall the business would have an idea, send it off to the BA's to document, it would then go to an Architect or Technical Lead to design and then off to the developers who would implement the feature, or set of features. The biggest challenge with this is the amount of leg work an idea has to do before getting implemented. In todays ever changing marketplace this method is slow, laborious and showing its age. Instead, what if the business talk directly to the developers? Lets consider that the BA and the architects are present as well. The business explains whats needed, everyone asks their set questions. Depending on the organisation business and technical requirements could be created prior to creating story cards and development tasks.

Timeboxed Iterations

Instead of working from start to finish on a feature, which could take upwards of months. All this time the client haven't seen a thing until you decide its finished and meets spec. At this time the client gives the "its exactly what I asked for but not what I wanted". Time boxed iterations force the larger tasks to be split up into smaller sections. I generally run with two week iterations, which means any tasks taking more than 2 weeks are broken down. When breaking these tasks down ensure at the end of each iteration you can show the client how the feature is progressing. If they choose to change the direction you know earlier than later.

I could keep going and going with the differences, but I won't bore you. I'll attempt to document some of the similarities in the coming articles! And take you through some of the roles of the Agile team members

agile waterfall