Who Needs an Architect?


Software architecture is one of those subjects in software engineering that’s still being actively developed and discussed, a testament of just how young computer science and software engineering are compared to other areas of engineering and in general human knowledge. Maybe it’s because of that or because it’s a highly abstract concept even if it wasn’t still discussed, that I’ve always struggled to get a real concrete understanding for what it is. I’ve never gotten past feeling of what it does or how exactly it should be done, and because of that I’ve never really known what to do about it on projects that I’ve been in a position to work like one of the architects. Now, this blog post we read made a great point about It, I really liked the way Martin Fowler, defines it as the significant components and design decisions that agreed upon by the expert developers tasked on a project. It makes things clearer on how to approach doing architectural design and it also helps me understand why I’ve struggled to get the concept before, because it changes a lot for each project because the things that are important to developers also change. Like the way developers working on enterprise applications think of the database as something super important while developers building other apps might think nothing of it which reflects on the architecture and design decisions. I genuinely think that just by approaching future projects thinking this way might make it so that I have a better time working on architecture as a whole, both filtering out unnecessary work and decisions and better choosing which components should be thought of as irreversible and which others I should try to make interchangeable or at least consider to do so at the expense of a bit of extra complexity.

Comments

Post a Comment

Popular posts from this blog

The 4+1 View Model

Software development is a pretty complicated endeavor, with a lot of moving parts and people working on them, and it becomes even more complicated because we as software engineers tend to behave a bit like the five blind men on this week’s videos and writings. We tend to only focus on the things that matter to us without any regard for the project as a whole. The people that are working with persistence want the data to have certain structure that makes it a better fit for the persistence architecture, and they do not care if that makes it easier or harder to use on the rest of the project. If they had their way the data would fit perfectly on the storage solution even if it had to be a frankeinsteinian blob of information. That’s why there’s a huge need for project-wise architecture and software architects, because is their job to be the wise man on Grady Booch’s story and calm the developers down, mixing their needs and priorities in a way that makes sense at a high...
Read more

An Introduction to Metaprogramming

This last blog post was really short, a lot more so than most of the others we’ve been reading so being honest I’m not really sure I have enough to say about it. It was very much an introductory kind of writing just showing a tiny bit of what metaprogramming is and a couple of examples of it in action. I do like the concept, metaprogramming is something I actually have used before, at first without realizing it was a known, named, thing and only realizing it was about a year ago. It’s a very useful concept, especially on those languages that can be done at runtime, meaning you don’t generate the source for other program but expand the running program’s capabilities while its running. Python, Ruby and JS are good examples of languages where its really easy to do some basic metaprogramming to make your life easier, although they don’t get to the levels of Lisp-based languages like Clojure that take metaprogramming to eleven by taking advantage of their really simple syn...
Read more