New-age Transactional Systems - Not Your Grandpa's OLTP
John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Posted by Scott W. Ambler on May 24, 2006
At Should Architects Also Code and Should Architects Also Code 2 Arnon Rotem-Gal-Oz has continued the long-running debate as to whether architects should write code. Although this is a debate within the traditional community, it isn't within the agile community: good architects code, end of discussion. Arnon agrees that architects need to participate in the project; the best way to test a design is to code and run it; it is beneficial for architects to know to code; and it is important that architects understand the implications of their decisions on the code and developers. This is a great start, and is actually quite forward thinking in the traditional world. Agilists take it one step further and take an agile approach both to project architecture and to enterprise architecture. Arnon's advice is superb within the context of a traditional environment, but isn't quite there yet for people in an agile environment.
It's an interesting debate either way.
Agile Maturity Model Applied to Building and Releasing Software
18 agile and lean practices for effective software development governance
In today’s hyper-competitive world, later may be too late to adopt Agile development and this Roadmap for Success will help you get started. Download "Agile Development: A Manager's Roadmap for Success" now!
Yes :)
Even if its just a little bit.
James
LogicBlaze
Fuse: the Open Source SOA runtime
Do the architects need to code?
Not sure if he is agile or not, but I know an architect guy coding every time he can (and he always finds the time to do it) :-).
./alex
--
.w( the_mindstorm )p.
Martin Fowler, which is probably one of the most known and influential software architects of our time, writes in his reviewed version of "The new methodology" (www.martinfowler.com/articles/newMethodology.html):
"The problem with a UML-like design is that it can look very good on paper, yet be seriously flawed when you actually have to program the thing."
and
"errors in the design that are often only uncovered during coding and testing. Even skilled designers, such as I consider myself to be, are often surprised when we turn such a design into software."
In our company one of the main benefit of agile, was that all people rebecame programmers, with the same rights. No more tester, analysts, architects etc. No more names. This put everyone in the same position, everyone designs, everyone tests, everyone designs. Soon enough some started to prove themselves better then others in certain aspects, by proving in front of the whiteboard and in code. They gained the respect of the others, by showing that they can do, not by being appointed or named by higher management. The design and code with the others but when they come with a design idea, because the others saw what they are capable of tend to accept it easier and embrace the ideas faster then when they had to do thing just because the ones that came with them were "the architects".
There is no more us vs them, and everyone can have objections. Since this big obstacle is out of the way, motivation is at its highest and work is done faster.
I think at the very least an architect should know how to code to some degree and be familiar with, if not proficient, in the language of code being implemented.
One of the better architects I've worked with knew architecture very well but he could program when he needed to. Granted, he didn't very often, but he knew enough that he could and by doing so, he communicated with the developers very well when it came time to implement his designs.
I remember being in a company long ago where they had these architect guys come in, draw all the lines and bubbles and then leave to do the same on some other project, while us developers had to then implement their designs. I think Agile is causing the demise of these ivory tower architects, since now all the key stakeholders need to be involved in the project in each iteration.
I don't think one could be a good architect without knowing how to code. The problem with coding however is that it tends to be forgotten if not exercised.
Loaded question!
Whenever needed, yes.
I have no doubt that most competent ones, who have a passion for the profession, do, and there is no way anyone can stop them from doing so. How else can one learn?
Again, should the architect lay the brick and mortar?
Seems extreme, but then there are project situations, when any kind of problem (be it due to bad planning, lack of ownership, or lousy competence) can be classified as a "technical" problem at an appropriate forum, and an "architect's" involvement is sought (fix this problem yourself) because...after all architects should code, right :-) ?
So, then, it depends on who is asking the question?
Are you a "manager", Scott :-)? Just kidding..
Cheers,
Ashok Shetty.
There is something that is confusing me somehow:
1) if they knew how to code, why are they hating it so much so they are not doing it anymore?
2) if they haven't known how to code, how they have reached the architect title?
I really think that in both cases, there is something fishy about these "architects".
./alex
--
.w( the_mindstorm )p.
You're not the first to notice this bad smell, Alex :-)
Some places wouldn't hire an "architect" without a modeling and coding interview with a senior developer. And even then, he'd have to accept relinquishing his special title - even the best are called Senior Developers in places like that :-)
deb
of course an arquitect has to code, i dont see another way of make a project successful if the "best" ideas are not coded by his author...
Do you assume, then, that the "best" idea is not likely to come from a new team member or a junior developer or even a tester? If you have hired well, you are missing some opportunities, there, imo :-)
John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.
Kevlin Henney examines code samples to see what can be learned from them starting from the premise that one won’t write great code unless he knows how to read it.
Jason Ayers share the observations he made watching a team of developers collaborating in real time on the same code base, pushing XP, pair programming and continuous integration to their extremes.
Michael Snoyman presents Yesod, a web framework written in Haskell and containing a web server, templating, ORM, libraries (templating, gravatar, etc.).
Richard Kreuter and Kyle Banker on how to avoid classical RDBMS transactional systems by using compensation mechanisms, transactional messaging or transactional procedures.
Attila Szegedi talks about performance tuning Java and Scala programs at Twitter: how to approach GC problems, the importance of asynchronous I/O, when to use MySQL/Cassandra/Redis, and much more.
One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.
InfoQ spoke to the authors of Software Systems Architecture on a couple of new topics, the System Context viewpoint and Agile, which have been added to the second edition.
12 comments
Watch Thread Reply