Yeah, I got a framework for that …

trepenationDo you remember when they loudly pronounced “vinyl was dead”? Be it records, testing or development framework, whenever something new comes along, there follows an army of doom-merchants. Either for the kick, or for profit, pronouncing something is dead is a easy way to get peoples’ attention. After all, what is better than something that’s past being kicked into touch, by something new. Maybe working out first if something new is better, or in fact, an over-hyped pile of crap. If you have worked in tech for 10 years, you will know what I mean when I say I literally wince in pain, when I hear someone’s warbling on about the latest framework product, that just blows away the competition. Even if the product wouldn’t even exist, if it wasn’t for it’s OAP predecessor (i.e. the language it was coded in).

I am reminded of time a professional colleague told me that as part of his learning of php, he built a user-friendly content management system from scratch and website templates for a client. It took him less than a month, and of course, he knows it inside and out.  I, on the other hand, chose the WordPress framework – and although implementation is quick, I still spend month of two configuring, adding plugins, refactoring plugins, etc.. Both are ways to get the job done effectively, but the smokescreen of frameworks is that they save time. They don’t. It’s two ways to do the same task. But the former provides you with something truly relevant, with no dead weight. Anyone who thinks otherwise is kidding themselves. I love WordPress, but fully aware that I also need to understand php even more than the products built on it.

Having said that, having been through the first painful few projects, I can now quickly build a customised CMS and templates very quickly using WP. I guess the point here is when you sell up to a framework, it really only shows value if you use it on future projects, not just a one-off.  One of the early mistakes I made was in the first flurry of excitement, I quickly bloated the code, as requirements necessitated plugins, some custom, some from the bewildering array of free and commercial plugins.  And many don’t manage to stay the distance, and languish through under-development, ultimately becoming incompatible with subsequent WP versions.

With development frameworks take your pick to learn, with enough fashionably named JavaScript frameworks to keep you busy in bluffing your way in IT for the rest of your life. But be wary – your career is on a knife-edge if you base it on products alone. And there is always a risk of spending too much time learning, and working with one framework. Nothing last forever, but a programming language is highly likely to outlive any product that is based on it. So feel pick Rails, Grails, Zend2, CakePHP, dotNET(?), Joomla (frameworks large and small) … not to mention the array of plugins and module they all have to extend the functionality.  But be conscious you are skipping across the surface of the tech, and what provides quicker routes, often come with more risk. If you are looking for a framework to use for your project, ask yourself why you are, before deciding.

At application level, I am wondering if there is any real valid excuse for using a framework. They don’t save time and they certainly don’t seem to save money in long-term. And there will always be compromise, sometimes at cost of client requirements. Start-ups can have valid excuse to use frameworks to accelerate initial development forward, but if you are looking something robust and future-proof, maybe you are better off with a “primitive” approach … a programming language takes a lot longer to die, than a framework.

Test Strategy Example

Test Strategy example

Test Strategy exampleTest strategies are often omitted because no-one ever reads them. And why aren’t they read? well, sidestepping “laziness”, it’s that too often they are unhelpful. So instead of sighing and drumming up something useless, why not generate something useful instead. Click here to view example of a risk based test strategy.
Continue reading

Grammar-oriented programming

What the biggest risk in development (leaving out frightening common omission of unit testing)?   That what is written down as requirements suffers a chinese-whispers style path to code.  TDD was an approach to address that risk, by saying that before functional coding starts as test based on requirement is derived, then functional coding done to pass the test.   Oversimplifying the nuts and bolts, but that is general idea.

Continue reading

Agile Business

There are some good articles around at the moment about Agile and Business. The business approach to risk needs to change, avoiding Waterfall type check-points (milestones) to measure risk. An Agile project will stress under pressure of differing objectives between the Agile project and the business, if the old ways are not changed.
Continue reading

How Agile becomes fire-fighting

What is the obsession with saddling people with combined roles in Agile – and often they do not even know they have two – it’s assumed. The project manager was split into two roles – Scrummaster and Product Owner. I do not believe there was anything wrong with the role of project manager, but the Agile division made sense utilizing development management skills of planning and maintaining momentum, with the (assumed) business analysis and planning skills of the Product Owner. It makes sense on paper, but with the splitting of roles, comes more risk as you have to have the right two people. Very often the Scrummaster or the Product Owner falls into project manager role, due to weakness in one or the other.

In industries still early to Agile, they retain the usual Waterfall role structure, though development managers have become a rare sight. This actually doesn’t have to mean a disaster – the Agile roles are still fulfilled to some degree, although the Scrummaster/Product Owners are recombined into a project manager. In those circumstances the Project Manager will have a stressful time – and highlights that there is a good reason for the PM role split. To work in a Agile fashion is more demanding on planning, and it’s a bad situation if the project manager is spending 95% of his day on MSProject (or something less hideous).

Even worse scenario is when the Scrummaster and Product Owner roles are “missing”. Either through inexperience within the team, or people rejecting their roles by simply not performing them. Sounds strange? Look in any corporation and you will find this situation. The onus is that situation is that the developer(s) understand what is required to deliver an Agile project. But the stress this time is firmly in development camp – just the place where you not want a stress-overload. You will end up with a project that bounces around (and largely on the spot).

Comining roles can sometimes be sensible business move, but in Agile the roles are seperate for a reason. Ingore them, and dont’t even think “we’re agile!”. At best you will end up with a faster Waterfall struggle. If you are struggling to fill roles effectively, then maybe the methodology isn’t for you … not without changing your approach.

Is Waterfall that bad?

WaterfallWas Waterfall as bad it is perceived to be? Whilst the approach is not geared towards every project, dismissing entirely is an arrogance. When soemthing new and improved arrives, it is generally given a holy grail sell-job – to extent where anything previously is portrayed as redundant. What hasn’t changed too much is coding and requirements. No methodology radically changed anything in these areas, as they both NATURALLY adapt to project demands, assuming a strong project manager.

“[Waterscrum] refers to the notion of using Scrum as a process in an organization that uses waterfall-based checkpoints to manage risk.”

When I first heard the term “Waterscrum”, I dug a little deeper, and it is bigger concept than just a piss-take (though who knows, maybe that’s how it started). Waterscrum tends to happen by accident, when SCRUM (the most popular and understood of the Agile methodologies) clashes with Waterfall die-hards. This is largely down to a company hierarchy, and the demands of those upstairs is measure by milestones, not Sprints. You will never get the ideal amount of engagement from the stakeholder in a corporation, as you would do in a creative agency. Dedicated resources rarely occur in corporations. The question it raises is can you have both? Exactly how to do it. Everyone has heard throwing the baby out with the bath water. These Agile methodologies are largely aimed are development, around the Software Development Life Cycle. So why not keep it there, instead of pretending something radically new has happened with requirements (beyond reformatting into user stories). Waterfall had business analysts, Agile has Product Owner. Waterfall has project manager, Agile has Product Owner/Scrummaster filling this role. Waterfall has a Test Manager, Agile has ….. major oversight. Manual/Automated Testers in Agile fit in only as functions. Some try to bypass that “hurdle” all together and allow their control freak development team dictate. We in testing had to define that part ourselves, which led me to more current roles akin to QA Manager. Anyway, a little off the point for this post.

Agile promotes a philosophy, then capitalism ensured that philosophy became tangible and saleable. In the course of that effort came the marketing, and the Agile Manifesto becoming like a biblical text – open to translation. I am sure there are some people who specialise in Agile-specific services are genuinely good – regardless of the methodology. But there are many amateurs, who have seized on another buzz-word frenzy to captilise of companies paranoia they are somehow missing out. When Agile entered the corps, then the cracks really started to show. Startups and smaller companies tend to communicate frequently by default, and the environment is already a SCRUm dream setup. Try and apply in a larger company – you can strategise, plan and distribute your goals. But then who going to push it forward – police it, for want of better phrase. It could be completely against your current work culture.