Moving from coder to architect?
July 9, 2007 7:17 AM Subscribe
What tools, approaches, and/or books did you use to get beyond thinking of application design from a coder's perspective?
I am trying to move beyond fooling with code to design web applications. I lose more hours prototyping code and going back and changing things, and I'd like to develop more of an abstract, design-based approach to things and - if I prove any good at it - not write much code any longer. How did you make the move from developer to designer to architect?
I am trying to move beyond fooling with code to design web applications. I lose more hours prototyping code and going back and changing things, and I'd like to develop more of an abstract, design-based approach to things and - if I prove any good at it - not write much code any longer. How did you make the move from developer to designer to architect?
Response by poster: Well, I guess I am thinking less of design patterns - which I understand - and more how to approach designing an application that doesn't involve sitting down and writing some code. I just can't get past that, and am wondering if that's common or if I'm just a terrible designer.
posted by xmutex at 7:31 AM on July 9, 2007
posted by xmutex at 7:31 AM on July 9, 2007
Are you thinking of things like user stories? Maybe try User Stories Applied.
posted by GuyZero at 7:58 AM on July 9, 2007
posted by GuyZero at 7:58 AM on July 9, 2007
Check out the sort of "softer" series of books that Pragmatic Programmers has recently started rolling out, particularly Release It! and Manage It!. I was really surprised by Release It!. It's nothing really new or shocking, but it's really handy to have around in case you want to sanity check your approach to a problem.
Also, architects who don't code are architects I (and a lot of others) do not like to work with. As an architect, you should be the one doing foundational implementation and cherry-picking other parts of the application that might be interesting to you or very difficult or high risk. You don't need to get stuck implementing 50 screens, but you should be responsible for establishing the patterns and frameworks that will be used to implement them.
(I am sure that is a controversial viewpoint, particularly to those of you who have interests in MDA. I don't mean to derail this conversation into "what is an architect?" but I think it's important to at least offer my point of view. If you don't want to write software anymore, please don't decide to design it instead!)
posted by feloniousmonk at 8:22 AM on July 9, 2007
Also, architects who don't code are architects I (and a lot of others) do not like to work with. As an architect, you should be the one doing foundational implementation and cherry-picking other parts of the application that might be interesting to you or very difficult or high risk. You don't need to get stuck implementing 50 screens, but you should be responsible for establishing the patterns and frameworks that will be used to implement them.
(I am sure that is a controversial viewpoint, particularly to those of you who have interests in MDA. I don't mean to derail this conversation into "what is an architect?" but I think it's important to at least offer my point of view. If you don't want to write software anymore, please don't decide to design it instead!)
posted by feloniousmonk at 8:22 AM on July 9, 2007
You might want to try test-driven development, or agile/extreme programming. There's also a good book called Refactoring to Patterns, that basically outlines a process in which you design a test, write some code to fulfil that test, no matter how bad it is, and then refactor that code after it works to use patterns.
You have a huge head start if you're restricting your focus to web applications, because most applications exist within a framework. If you're using Java, you'll probably be using J2EE, maybe plus a framework like Struts, JSF, Spring, etc. If you're using PHP, maybe you'll be using CakePHP. If you're using Ruby, you're probably using RoR. That'll dictate design to a pretty large extent.
If you're not using that, thinking in terms of overall models will help a lot. Does MVC fit your application well? That's a pretty common one, and a very good place to start. The old PHP approach was 2/3-tier system, with DB abstraction, logic, & presentation layers, and this still works well for some applications. Some things demand a more modular system. It just really depends on what you're doing.
posted by devilsbrigade at 8:29 AM on July 9, 2007
You have a huge head start if you're restricting your focus to web applications, because most applications exist within a framework. If you're using Java, you'll probably be using J2EE, maybe plus a framework like Struts, JSF, Spring, etc. If you're using PHP, maybe you'll be using CakePHP. If you're using Ruby, you're probably using RoR. That'll dictate design to a pretty large extent.
If you're not using that, thinking in terms of overall models will help a lot. Does MVC fit your application well? That's a pretty common one, and a very good place to start. The old PHP approach was 2/3-tier system, with DB abstraction, logic, & presentation layers, and this still works well for some applications. Some things demand a more modular system. It just really depends on what you're doing.
posted by devilsbrigade at 8:29 AM on July 9, 2007
Probably the easiest way to start is by spending time analysing the systems and projects that you have been involved with. Understand the higher level business problems that they were built to solve and comprehend how the solutions were evolved - asking the people who made these decisions would be a good start. A good architect is generally someone who has a broad experience of different approaches and who can apply and modify them as needed to the project at hand. I should probably mention that I have always found this kind of stuff to come fairly naturally despite not having a technical education.
posted by zemblamatic at 8:37 AM on July 9, 2007
posted by zemblamatic at 8:37 AM on July 9, 2007
Are you asking about how to better visually concept your designs first with an eye toward better usability and work flow?
As a graphic designer, I've worked closely with devs to develop and build interfaces for web apps. So , I have some definite suggestions from my point of view.
But, if that's not what you're talking about, I'll keep quiet.
posted by Thorzdad at 8:51 AM on July 9, 2007
As a graphic designer, I've worked closely with devs to develop and build interfaces for web apps. So , I have some definite suggestions from my point of view.
But, if that's not what you're talking about, I'll keep quiet.
posted by Thorzdad at 8:51 AM on July 9, 2007
If you want the thorough, academic treatment, Sommerville is probably the go-to-guy. It's one of the standard textbooks on software engineering, the area of study into which the development and evaluation of architectures falls. For your specific purpose, I'd recommend checking out chapters 4 (software processes), 6 (software requirements), 11 (architectural design), 16 (UI design), 17 (rapid development), 18 (software reuse) and probably 23 (software testing).
posted by Herr Fahrstuhl at 9:18 AM on July 9, 2007
posted by Herr Fahrstuhl at 9:18 AM on July 9, 2007
Joel on Software has some great book recommendations.
In fact, the whole of the Joel On Software is worth reading.
posted by seanyboy at 9:38 AM on July 9, 2007
In fact, the whole of the Joel On Software is worth reading.
posted by seanyboy at 9:38 AM on July 9, 2007
You might want to check out the 37 signals book. It's pretty good. I liked it.
posted by chunking express at 11:10 AM on July 9, 2007
posted by chunking express at 11:10 AM on July 9, 2007
This thread is closed to new comments.
posted by cschneid at 7:28 AM on July 9, 2007