I’m befuddled by something my company is doing. They’ve decided to do a hackathon and are really pushing everyone to participate in it. I used to be a software engineer, so I know what a hackathon is. A team of developers lock themselves in a room (not literally) for several days or a week, working around the clock to develop some… thing. It’s a creative process for developers in sort of a contest format. I’m good there.
What confuses me is that the business analysts are getting just as much social pressure to participate as the developers are. Am I off base in thinking that there’s no place for a BA in a hackathon, except perhaps to propose an idea or bring in pizza? Due to the time limit there’s really no time to write requirements. So… what do they expect us to do, really?
I would ask the hackathon organizer what role they expect the BAs to play. They may be there just to make sure that what gets developed meets the needs of the business.
I guess it could be worse, why leave out the project managers?
Really, this kind of event tends to be remodelled to suit the politics of the company.
They want some of that dotcom magical energy but don’t see the need to change the way they do things.
Most companies, when they get to the size where they are dominated by their internal conversation, see the outside world as a series of fashion statements that may or may not be useful in their deliberations. They only really change the way they do things when they are in serious trouble, the rest of the time, they live in their own bubble.
Humour them and try to find some job for the analysts to do that makes them think they are involved and making a contribution but keeps them quiet and out of your hair.
I would assume some managers were part of the decision making process to include them. Perhaps there intended purpose is to simulate real world circumstances where rapid development will be hindered by management.
The BAs might be subject-matter experts on some business process related to whatever product might be the goal of the event - so they might work collaboratively with the developers, even if only as a sounding-board for ideas.
Given what you’ve told us of your employer, it seems pretty obvious to (deeply cynical) me.
The head moronic PHB heard the word “hackathon” somewhere and wants some if it, whatever it is. The second tier moronic PHBs said “Yes Sir!”. And now you’ve been given a hackathon. Do not seek more meaning in it than this, for there is none to be found.
Which hackathon will be just as effective, well-run, and useful as the rest of this benighted company’s efforts.
Lol, LSLGuy, I’m in agreement with you. (I was really wondering if I was completely off base and BA’s in other companies dive right in with the developers in a hackathon.) Given the issues (I’ve mentioned in other threads), and a recent poorly executed attempt to start changing the culture from extremely risk averse to innovative, I think this is part and parcel of that. They are grasping the easy gestures like cheerleading a hackathon over real culture-change (like dumping the toxic VP).
This part is true. We’ve all been encouraged to send in ideas. But there’s no need for us to participate IN the hackathon. Remember, a hackathon is <start stopwatch>round the clock coding and testing until <end stopwatch>. The idea makes me think of some BA’s getting belted by frustrated, sleep deprived developers for butting in and slowing them down.
Having done some development (mostly web-based these days) having access to a SME is very valuable. Even if you have content already written ahead of time it is nice to be able to have someone to clarify things and sometimes what a person wants is impossible or at least inadvisable so you’d want to check with them about an alternative.
But I don’t see having someone there around the clock. They’d be spending a lot of time doing nothing. I agree that this request surely didn’t come from the tech guys. If anything they’d ask to have someone available but they wouldn’t want someone hovering around that whole time.
IMO the “interesting” features of a real hackathon are these:1) The idea that developers have (on their own) ideas that would be commercially useful. Ideas which the business will otherwise ignore or pooh-pooh.
The idea that the typical process bureaucracy of commercial development is an obstacle to at minimum rapid prototyping and at maximum, well, everything useful in software development.In principle I don’t see why BA’s couldn’t be just as useful for 1). The ability to write code is not a prereq for a useful business or product idea.
But when it comes to 2), BAs are generally seen as part of the problem *not *part of the solution.
Which makes me think that net, net, BAs are detractors from a canonical dev-centric hackathon at a company where there’s any hope of the process being worthwhile. And they’re doubly detractive in a broken company.
IMO the way to legitimately do the “no holds barred, wildcat innovation” thingy with BA’s is to have a brainstorm-a-thon just for them, where they burn the midnight oil solo or in small teams to discover some novel problem & invent a solution, flesh it out using their skills as far as they go, and stop right there. With deliverables not of running code, but of story boards, use cases, and broad-brush requirements that at least pass the laugh test without to much of “Step 3. Then a miracle occurs”. See About | Then a Miracle Occurs . . .
The same kind of thing can be done with the IT infrastructure folks. They’re usually too busy keeping the existing mishmash of servers and services running to back off and look at how they might rehash the whole thing for better performance, reliability, deployability, and all the rest of the “ility” soup. Turning each of them loose in a garden of fresh blank VMs can produce some real magic sometimes.
What IMO is a waste of time is to try to do a mash-up of dev, BA, & IT. That’s just like doing a three-legged sack race with a giant, a midget, and a hyperactive St. Bernard. The impedance mismatches between teammates overwhelm the hoped-for gains from blowing off process and creating buzz, excitement, & competitive spirit.
I think it really depends on the size of company and the type of work being done.
For most enterprise-y stuff, things are too complex to only have devs and create something of value to the business. You need information that resides in multiple groups of people (e.g. fa’s, ba’s, users, etc.).
If they are following the “agile” or “scrum” (a type of agile) development method, then part of the process is that everyone is involved at every step of the process.
In traditional programming, the BAs would write up requirements for what they want. This would be handed off to the development team, who would the develop the product or feature. The BAs wouldn’t be involved again until the product was delivered. Then the BAs would complain that the product doesn’t fit their business cases, the developers would complain that the requirements didn’t adequately describe what was needed, etc. and so forth, lots of blame and pointing of fingers, and no one is happy with the end result.
There are a lot of different ways to do agile programming, but the more common methods like scrum do iterative development cycles. Instead of the traditional development method, tasks are broken down into tiny chunks with frequent reviews. So instead of developing the entire product and showing it to the BAs, the developers might come up with a prototype just to show how the screens are laid out and what features they plan on putting in and how they would be accessed by the end user. The BAs sit in on these reviews, so if this doesn’t fit their business cases, they have to say so right at the start before anyone goes off and spends gobs of time writing tons of code. Then the developers add in some new features, and demo those to the BAs, and to management, and to the test group, who also iteratively tests things during development so that they don’t have to wait for an end product, drastically shortening the test cycle. Everyone gets their input at every stage of the process. This is why you need everyone, including management, test, documentation, etc. involved at every stage of the process. In some businesses, they even get the customers or end users involved, just to be certain that the final product is what everyone wants.
Hackathons always seemed to me like a way to make sleep deprivation and working overtime sound “fun”. If it’s so great, why can’t you do it during regular business hours? Do people get a few days off for rest that doesn’t come out of their vacation time after an event like this?
My last company would have hackathons that included non-technical people. In the morning (well, about 10:30-11:00) a group of developers would give presentation on a particular technology, and part of their prep work for the hackathon would be to set up a base project that could be quickly set up on people’s laptops. Then for the rest of the day everyone would work on their own little modifications to that base project. There were no teams, everyone was encouraged to share what they were doing with everyone else the whole time. The people who gave the presentation would generally just help everyone else out.
It worked well for things like OpenGL 3-D programming, where there were simple built-in things that anyone could implement, but more experienced developers could dive into more advanced topics. It didn’t work quite as well for my stuff, because database and backend system development is boring, even for those of us who do it. I wound up making my hackathon about how to use the Slack and Twitter APIs.
It was really meant to give people in other groups a sense of the kind of things a given group might be working on, not so much to produce anything useful.
I really liked this format, but it did give the presenters a lot of extra work leading up to the hackathon. And I never actually got to fully participate, as every single time we had one I got pulled away onto a production issue.
I agree with this totally. Just let the thing pass, look like you are being a interested for this event and let it pass. Because if you say anything against it, you are considered the one who isn’t playing the company game.
I’d never heard of “hackathon” and am slightly aghast. Back in the 1970’s when we were bright-eyed technogeeks, we put in plenty of very long sessions, compensated or not, when they were urgently needed. (And by “urgently needed” I don’t mean responding to a tomorrow deadline we knew about two months before.) Other days I might saunter in at noon.
Is a “hackathon” some attempt to artificially recreate an old-style work ethic / comaraderie?
I wouldn’t criticize it for being artificial, it’s just a different time and place. 40 years ago the landscape was unsettled, you could lay the foundations of a new city with a weekend coding binge. There isn’t much untouched land to build on anymore but the experience is still worthwhile so the hackathon is an opportunity for the what may be the last generation of human software development to get that feeling of accomplishment. I even considered participating in one of these things at work after our company’s team got their asses kicked in the post-event bowling competition.
My company had a hackathon like this. Everyone on the “technical” side was technically on a hackathon team.
The QA people had nothing to do, so they usually ended up as presenters so they could make slides or something. The DevOps people all begged off to do actual work instead of the hackathon, but they wouldn’t have been able to do much anyway. The BA/PM/PO people were there to bounce of ideas off, but they were about as useful as QA. Luckily the head PM wanted some strategy meeting and they all left. The DBA were useful for writing queries, but 90% of the time, that meant they were either done the first hour of the hackathon or they didn’t have anything to do because the queries were so easy the devs could write it faster than they could explain what they needed to the DBAs.
One team sent their non-technical members to [del]sabotage[/del] “make small talk” with other teams. It was only successful on the team that was a giant clusterfuck anyway.
In general it sounds like your management top-down decided to have a hackathon and “everyone should be involved” without really thinking about what that meant. I will say that, out of the 7 teams my company forced into a hackathon, six of them made projects that have either made it into production or are slated for a later release, so it wasn’t a waste of time. (The 7th made something that was a fine idea but couldn’t be monetized).
If you have to go, I’d see what I could do to make the devs lives easier. Gophering pizza and drinks, clicking through screens to catch the kind of bugs that show up in a demo, etc. But you’ll probably be bored most of the time.
