Architects Need a Pragmatic Software Development Process | Hacker News Reader

Architects Need a Pragmatic Software Development Process

javacodegeeks.com

18 pointsnikosmar12 comments

"Working this way, everything becomes quantifiable, predictable, comparable and traceable."

And laughable.

What architects need to do, is write lots of production code, so they recognize that none of those things is easily achievable, if even possible.

Yes! And write it using the stupid, stupid "corporate standard" tools (Serena Dimensions, I'm looking at you) that their employer mandates for whatever political reasons.

Just managed to get rid of SPARX Enterprise Architect here - we're on digital whiteboard, balsamiq and plain use cases now and it rocks.

Agreed! Most emphatically so, in fact.

I've been an "architect" since 2001 and the thing that slaps me in the face again and again is that most architects I encounter can't code, or haven't bothered to for years.

First, the word architect is just a fancy word for design. And yet most architects don't know the difference between a layer and a tier. The best way to get your head around those concepts is to write code using separation of concerns, and deploying it. Yourself.

Next, process. Seriously? Process was solved in the 80's. The agile movement brings nothing new here. There's a basic process that starts way before you write code -

Envision (your idea)

Plan (how)

Build (write the code - you can use SCRUM et al here if that's your bag)

Stabilise (bug fix - if your dev methodology permits then this merges with build, but an architect/project manager/program manager should still identify milestones for release readiness)

Deploy

Operate

Companies like Thoughtworks (whom I admire for their technical ability) will tell you to screw any process, and that the software will evolve itself. This is bad, because it will result in an app that's never finished.

So as an architect remember to begin with the end in mind. There's no point in starting if you don't know how to know that you've finished.

If process is new to you, check out version 3.1 of Microsoft's Solution Framework. Both the team and process models are good, but neither are gospel.

Stay VERY VERY far away from frameworks like TOGAF. They're a prime example of how to kill a project through process. The Zachman Framework is only good as a documentation guide, but offers little that the Microsoft Solutions Framework doesn't cover. The Unified Process, or whatever that crazy process is called that came out of the UML world is just as bloated and useless.

In closing, if you want to be a good architect, learn to code better than anyone else you work with. Be that guy that's done it all and has the war stories to prove a point, like why server push won't work on an ADSL network.

And don't call yourself an architect. You design software. That's kind of it.

Another "architect" here (actually just a slightly better paid, higher skilled developer and as you say full of war stories).

I think you pretty much hit the nail on the head there :)

The amount of other architects I have to deal with from big well known organisations over the last few years is scary. My team are the only guys I have met who get outside of Word, Project and Excel and actually put pen to paper so to speak.

Avoid ALL process frameworks entirely though, including MSF which is a rotten turd. The only process I've seen that works is:

backlog (arc/business) -> design/review (arch) -> build (arch/dev) -> test (arch/test) -> deploy (arch/operations).

Note the total involvement of architecture teams.

I quite like MSF. The milestones and deliverables it advocates are a good pick-list and sanity check. That said, I think anyone new to process could learn a lot from it, because it's based on Rapid Development (ref. Steve McConnel's book with the same title).

Anyone new to process should similarly understand and (ideally) have used all the other usual suspects, from RUP to Waterfall. The premise being that you can't really argue against something if you've not experienced it for yourself.

I've worked under MSF, RUP and good old waterfall. They're all dead ends if you ask me, even delivering massive enterprise software. To be honest these processes were fine with earlier tooling such as Visual Basic which was rigid, inflexible, hard to test etc but (whilst wincing using the term Agile), there are much more agile languages now which allow test frameworks to be built effectively.

We've settled finally on a hybrid Kanban approach. It's simple, everyone understands it, there are no power trips, it just works.

backlog -> arch -> dev -> test -> deployed

There is no agile ceremony or SCRUM-wankery (pigs, chicken shit) - we binned all that and just did work.

In my experience, the software architects I've known were turkey farmed into their roles because the management structure couldn't figure out what to do with them. Most were actually good at coding, not very process-y, and carried good opinions about software design. As developers, they were rightly recognized for their contributions and promoted for them. But as architects they became organizationally peers to management, and they invariably got sucked into internecine management politics, which neutralized their abilities.

The irony of this is that I think all software engineers should carry these traits. Having software architects just stuffs this role into a handful of people instead of spreading it throughout the organization.

I have an extremely hard time taking seriously the use of "architect" to describe anything other than someone with an M.Arch or B.Arch who is employed designing buildings.

I would say that it's pointless ego stroking, but I know a lot of actual architects, and they'll be the first to tell you that it isn't exactly a high-prestige title.

We only accept the title because it comes with an extra £20k :)

I must say, as an architect (the M.Arch kind), I find the use of the word "architect" when talking about computers, especially without the word "software," cringe-worthy. But I'm kinda getting used to it. In terms of software, you're right, it's probably ego stroking, or maybe it was started by Howard Roark fans. I also chuckle when I read start-up / tech blogs, or resumes, use the word "architecting." I guess it really is a cool word in the software world.

In terms of actual architecture, it used to be a professional title that implied someone highly qualified to design buildings, able to take on fiduciary responsibilites just as well as any other professional. But the profession is in such a sorry state right now. Architects have a bad rep, and rightfully so. Definitely doesn't have that kind of prestige anymore that was present in the first half of the 20th century.

The new meaning of Architect: a little more pay (like gouranga said), and a lot more liability.

This already exists: http://quadrant.tumblr.com/

Reply on news.ycombinator.com