tag:blogger.com,1999:blog-8509343272562195687.post6224430457371991106..comments2024-03-16T00:50:35.056-07:00Comments on IEEE Software Blog: Why Should Software Architects Write Code?Mei Nagappanhttp://www.blogger.com/profile/03225600742361609176noreply@blogger.comBlogger31125tag:blogger.com,1999:blog-8509343272562195687.post-29573735682475680642016-09-28T15:38:10.756-07:002016-09-28T15:38:10.756-07:00It seems to me that this survey provides some evid...It seems to me that this survey provides some evidence that developers who have some understanding of architectural principles make fewer mistakes when developing and changing architecture-related code than those developers who lack this understanding. Like skumar suggests above 'hire architecture-savvy developers' would seem to me to be the valid conclusion of this survey.<br /><br />What the survey does not really help us with is the key question - 'To what extent should the architect of a particular software system be involved in the programming of that system'. Like most software engineering questions, there's no easy answer. Sometimes it makes sense for the architect to be involved in the system from its outset to its delivery and maybe even its support. Sometimes, however, say when a system is developed by multiple organizations by developers speaking different languages, the best use of the architect is during the early stage of systems engineering not in the coding process.<br /><br />So, the question 'Should software architects write code' is not really a very good question because the only universally valid answer is 'It depends'. We can only answer the question more specifically if we define the context of work . <br /><br />What you have provided evidence for is the need for all developers to understand architectural concepts and principles and it is a pretty sad reflection on computer science education (and other programmer education programs) that so many developers don't seem to have this understanding. Ian Sommerville.https://www.blogger.com/profile/08250241252861339865noreply@blogger.comtag:blogger.com,1999:blog-8509343272562195687.post-29734318114129932982016-06-08T08:46:38.065-07:002016-06-08T08:46:38.065-07:00Thanks for your comments!!! I'd be happy to se...Thanks for your comments!!! I'd be happy to send you a copy of our results. Please drop me an email!!! In this article we planned to provide empirical evidence for pragmatic views on architecture and coding. Mehdihttps://www.blogger.com/profile/15679291441239558381noreply@blogger.comtag:blogger.com,1999:blog-8509343272562195687.post-19707153443720242452016-06-08T03:07:58.098-07:002016-06-08T03:07:58.098-07:00Wow! Very interesting post, I am really happy to s...Wow! Very interesting post, I am really happy to see that I am not the only one with these ideas. This post looks really similar to one I wrote last year, based on my own experience: http://missarchitectblog.blogspot.nl/2015/11/do-architects-need-to-write-code.html. I am curious to see the results of your investigation, it can help me to prove my point :)Miss Architecthttps://www.blogger.com/profile/00412644740889113144noreply@blogger.comtag:blogger.com,1999:blog-8509343272562195687.post-16953187584498690592016-06-01T01:45:54.435-07:002016-06-01T01:45:54.435-07:00These cell telephones have been completely changed...These cell telephones have been completely changed and each kind of observable break has been available. They have been revamped to the creation most recent state. <a href="http://thecracksoftwares.com/driver-toolkit-crack-download-keygen/" rel="nofollow">driver toolkit crack</a>Sarahhttps://www.blogger.com/profile/01618128254174522484noreply@blogger.comtag:blogger.com,1999:blog-8509343272562195687.post-5404245133615941292016-03-10T13:01:14.435-08:002016-03-10T13:01:14.435-08:00Thanks for the feedback! Agreed!!!Thanks for the feedback! Agreed!!!Mehdihttps://www.blogger.com/profile/15679291441239558381noreply@blogger.comtag:blogger.com,1999:blog-8509343272562195687.post-89631804521332393712016-02-29T10:31:29.971-08:002016-02-29T10:31:29.971-08:00The second observation can be explained more gener...The second observation can be explained more general: It is most of the time easier to implement a quick and dirty local solution what will work for the Happy flow simple testing. Code/Design reusing is a case of continuous learning en syncing with each other...Anonymoushttps://www.blogger.com/profile/05764340895516596101noreply@blogger.comtag:blogger.com,1999:blog-8509343272562195687.post-35563002126505634562016-02-25T23:35:52.345-08:002016-02-25T23:35:52.345-08:00That's what i got from the book "software...That's what i got from the book "software arxhitecture for developers," cited above. Adamhttps://www.blogger.com/profile/04627756320001286885noreply@blogger.comtag:blogger.com,1999:blog-8509343272562195687.post-60630969718126840982016-02-25T09:33:04.276-08:002016-02-25T09:33:04.276-08:00Hi Mehdi, I'd like to read your work too!
(So...Hi Mehdi, I'd like to read your work too! <br />(Sorry if I'm not indentified here)<br />My name's Marvin (from Brazil), my email is marvin@usp.br (University of São Paulo - Brazil) Anonymoushttps://www.blogger.com/profile/10829100446665332348noreply@blogger.comtag:blogger.com,1999:blog-8509343272562195687.post-14515308528377827732016-02-24T15:10:46.587-08:002016-02-24T15:10:46.587-08:00I enjoyed reading this! Thanks for sharing your ex...I enjoyed reading this! Thanks for sharing your experience!<br />MehdiMehdihttps://www.blogger.com/profile/15679291441239558381noreply@blogger.comtag:blogger.com,1999:blog-8509343272562195687.post-66210593322567860352016-02-24T15:08:30.751-08:002016-02-24T15:08:30.751-08:00Thanks for the feedback!
Question, How can one be...Thanks for the feedback! <br />Question, How can one be a good developer if he/she doesn't know how an MVC pattern, client-server style, fault detection design, or many other design choices work. What about trade-offs between performance and security choices? At the end of the day, our software systems will have an architecture, and developers work within the framework enforced by that architecture, missing the design knowledge can compromise software quality.Mehdihttps://www.blogger.com/profile/15679291441239558381noreply@blogger.comtag:blogger.com,1999:blog-8509343272562195687.post-82016521617896232042016-02-24T15:04:13.608-08:002016-02-24T15:04:13.608-08:00Hi Simon, Thanks for the feedback.
One interesting...Hi Simon, Thanks for the feedback.<br />One interesting point is that actually a good number of the developers in non-architecture savvy group were senior developers with years of experience but not necessarily architecting experience. So we don't make the assumption that developers are people with little skill.Mehdihttps://www.blogger.com/profile/15679291441239558381noreply@blogger.comtag:blogger.com,1999:blog-8509343272562195687.post-19325338746515343452016-02-24T14:57:31.910-08:002016-02-24T14:57:31.910-08:00Thanks for the comments Waleed!Thanks for the comments Waleed!Mehdihttps://www.blogger.com/profile/15679291441239558381noreply@blogger.comtag:blogger.com,1999:blog-8509343272562195687.post-8304920024513775892016-02-24T14:57:06.727-08:002016-02-24T14:57:06.727-08:00Thanks for the feedback!!!
I very much like differ...Thanks for the feedback!!!<br />I very much like different pieces of your comment (e.g. fear of UserGroupInformation, Architects write tests, design for testability, etc.) I would love to be in touch with you for a follow-up study. I've been impressed by the amount of design knowledge shared between Hadoop developers. Next step for us is to interview someone from Hadoop project, If you are interested, please drop me an email (mehdi at se.rit.edu)<br /><br />Thanks for the comments. I didn't describe the details of the methodology used for this study in the blog post, but I'm going to put that online.<br /><br />The roles were identified through developers LinkedIn profiles plus a complimentary step. <br /><br />Yes we looked at code commits, and JIRA. We extracted the developers emails account, looked up their profile on social media (e.g. Linkedin) Primarily we used the work history reported on LinkedIn to see if they have previously served as an architect or not. So many of the architecture-savvy developers were identified through self-identification on the LinkedIn profile. We also looked at the developers discussions on JIRA and their comments within the commits. That info gave us complementary data on who is architecture-savvy and who is not architecture-savvy. These data were peer-reviewed to gain higher confidence. We had senior developers who were in the non-architecture savvy group because we couldn't find evidence that they have served as architect role in the past (through LinkedIn) through their comments we didn't find discussions related to architecture. (Note: This dataset has been kept fully private, sometimes we researcher need such datapoints to provide empirical support for what's happening in practice)<br /><br />Buggy files were identified by matching commits and JIRA reports. This is a common method, and the most reliable technique so far. Yes, we differentiated the bugs from enhancements and other changes. It requires matching GitHub commit histories with issue tracking systems.<br /><br />The tactical files were detected through our reverse engineering approach; we used higher thresholds to include files which very high confidence in the study. Mehdihttps://www.blogger.com/profile/15679291441239558381noreply@blogger.comtag:blogger.com,1999:blog-8509343272562195687.post-74501584062077220992016-02-24T12:12:57.136-08:002016-02-24T12:12:57.136-08:00As I mentioned, I'm both an architect and team...As I mentioned, I'm both an architect and team lead so my perspective is slightly different than people who are pure architects so keep that in mind.<br /><br />The frequency of me getting involved is directly related to how often changes to the way the developers approach things change. Developers tend to learn an approach, get familiar and comfortable with it and then that becomes how they handle all new projects. Over time this starts to become stale. The field moves forward to solve common problems, introduce better abstractions, libraries mature or die and are replaced, etc. It's necessary to "refresh" our approach from time to time. That's when I end up getting involved. I'd say a handful of times a year we introduce a change that requires some coaching and monitoring and often that includes writing code to either demonstrate the concept or actually implement one component to use as the guide for developers to implement the rest.<br /><br />Each new topic has a drop-off where I spend a lot of time up front making sure things are done correctly and that people understand the how and why. As the developers become accustomed to the change, my time required for that change is much less to the point I'm not needed at all by the second or third implementation leveraging that design element. When that happens, I introduce a new change. It's a slow process of constant improvement. I look for a high-value change that can be made to make things easier for the developers or more robust or gives new value in the applications, etc., add it to a design, work through an implementation and then give some time for it to become routine. Then I identify the next high-value change and repeat the process. Changing too many things at once is very risky as it becomes difficult to track down exactly where problems are and as the architect I become the critical resource for many developers to resolve their issues. It causes developers to fall back to "the old way which worked perfectly fine" and makes introducing changes in the future an uphill battle.<br /><br />I'd say the amount of time I spend on design is eclipsed by time spent coaching, providing reference implementations, answering questions and debugging problems but I think it's important that I do these things to make sure I'm not setting the developers up for failure. I made that mistake by telling the developers to use repository pattern to make DI easier without explaining what I meant or providing a reference and then spent a lot of time pulling things back together. Conversely giving them a reference for DI using a specific library was quite successful. I'm actually currently working on a new reference implementation of some new things we've been asked to start including in projects going forward which includes better error logging and the inclusion of application profiling because whatever our next project is will have to have these features.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-8509343272562195687.post-91736123311508437042016-02-24T11:56:34.470-08:002016-02-24T11:56:34.470-08:00"Simon Brown [...] advocates increasing the d..."Simon Brown [...] advocates increasing the design knowledge of developers..." What if they don't want more design knowledge? IME, many of these developers are quite happy as they are...? Pattern-chaserhttps://www.blogger.com/profile/09525856532112611070noreply@blogger.comtag:blogger.com,1999:blog-8509343272562195687.post-5742984613311930882016-02-24T11:24:18.534-08:002016-02-24T11:24:18.534-08:00I thought these comments were interesting "Si...I thought these comments were interesting "Simon Brown argues that most software developers are not architects or do not have extensive design skills. " and "Developers with little or no background in architecture and design struggled to implement architectural patterns/tactics. "<br /><br />Which is to say, the author defines "Developers" as people with very little skill or experience, and notes that when some experienced people got involved, things worked better.<br /><br />So you could really call this piece "why you should hire a few competent and experienced developers rather than expecting a bunch of unsupervised juniors to do useful work on their own." <br /><br />But perhaps that conclusion would be a tad obvious?<br /><br />Simon RitchieAnonymoushttps://www.blogger.com/profile/06315166576283564372noreply@blogger.comtag:blogger.com,1999:blog-8509343272562195687.post-44030258478091805842016-02-24T10:30:46.366-08:002016-02-24T10:30:46.366-08:00Thanks Dr.Mehdi, it a very interested study and I ...Thanks Dr.Mehdi, it a very interested study and I can say that I totally agree on the important role of the architect with the team and that this role should include more than just the design and high-level decisions. Anonymoushttps://www.blogger.com/profile/08913803799935706813noreply@blogger.comtag:blogger.com,1999:blog-8509343272562195687.post-14815007681931759262016-02-24T09:52:04.742-08:002016-02-24T09:52:04.742-08:00As one of the Hadoop committers during the time pe...As one of the Hadoop committers during the time period in question (stevel@apache), I am very interested about these findings, and would love to be a reviewer.<br /><br />In particular, I'm curious about<br /><br /><br />-How did you determine authors of patches? As it is often not the committer. I assume you went through JIRA, right?<br /><br />-What did you conclude about my role? High-level architecture or low-level things like diagnostics and getting tests to work?<br /><br />-How to define "strategic" vs "tactical" files? This is an interesting topic: if we can identify them automatically, then that's taking some of our folklore (leave "FileSystem alone") and making it visible.<br /><br />-Similarly, how good was you analysis tool at inferring "troublesome" files. I guess we have that information (the one with the most diffs), but really the nature of the patch type/JIRA issue needs to be included, to find those files which get the most bug fixes rather than enhancements.<br /><br />Some bits of code may seem tactical (UserGroupInformation; IPC Client and Server) but they are trouble not so much due to code quality, but they are the interface to stress points in the cluster, Kerberos and the network itself. They fail in ways which could be described as "interesting". We're scared of them. I don't know how they'd fit in to this tactical/strategic role, but certainly in the case of UserGroupInformation, the reason it doesn't get refactored or edited much is not due to contentment with its architecture: it's fear.<br /><br /><br />I don't disagree with the premise: architects need to code. I also think they need to write tests, to understand how to design for testability, and get involved in the low-level issues of metrics and monitoring, of deployment and fielding support calls: otherwise you don't get systems designed for management and supportability. I'm pleased to say my colleagues and I do get to do all this, including fielding support calls about UGI if we are particularly unfortunate. It only takes a few weekend-long support calls related to a part of the system before you start to see flaws in its current design.<br />SteveLhttps://www.blogger.com/profile/07654931341335136008noreply@blogger.comtag:blogger.com,1999:blog-8509343272562195687.post-29199465118744740002016-02-24T09:50:26.387-08:002016-02-24T09:50:26.387-08:00Thanks Erik for the comment. I'm glad to hear ...Thanks Erik for the comment. I'm glad to hear from someone who is serving as an architect. You are articulating an interesting point and I certainly will use that in my next blog post. Out of curiosity, how often do you get involved with implementation issues? Either coaching the programmers or going over a coding problem with them that relates to architectural choices?<br /><br />Thanks<br />MehdiMehdihttps://www.blogger.com/profile/15679291441239558381noreply@blogger.comtag:blogger.com,1999:blog-8509343272562195687.post-8333626860878781202016-02-24T09:40:38.963-08:002016-02-24T09:40:38.963-08:00Thanks Julien for the comment, I enjoyed reading i...Thanks Julien for the comment, I enjoyed reading it, I agree this issue expands to the other roles in our industry. Mehdihttps://www.blogger.com/profile/15679291441239558381noreply@blogger.comtag:blogger.com,1999:blog-8509343272562195687.post-31958320870047690962016-02-24T09:31:22.096-08:002016-02-24T09:31:22.096-08:00Thanks Francis for the feedback, agreed this is a ...Thanks Francis for the feedback, agreed this is a very insightful point.Mehdihttps://www.blogger.com/profile/15679291441239558381noreply@blogger.comtag:blogger.com,1999:blog-8509343272562195687.post-50875297545934101752016-02-24T09:30:07.801-08:002016-02-24T09:30:07.801-08:00Thanks for the feedback, Yes that's definitely...Thanks for the feedback, Yes that's definitely a good take-away here.Mehdihttps://www.blogger.com/profile/15679291441239558381noreply@blogger.comtag:blogger.com,1999:blog-8509343272562195687.post-13278649333436229012016-02-24T09:19:30.744-08:002016-02-24T09:19:30.744-08:00I am an architect and team lead so my view might n...I am an architect and team lead so my view might not be the same as others but I emphatically agree architects should code. It's absolutely necessary for architects to have practical, continuing experience with the patterns, approaches, library decisions, etc. that they're making. That said, an architect should never be on the critical path for delivery when it comes to code. What I mean is, if an architect is put in the position of having to implement features on a timeline, they won't be available to coach, solve problems, revisit a decision, etc. at the architecture level without risking the timeline.<br /><br />To me that means pair programming is a non-starter when it comes to architects and developers. An architect needs to be focused on the bigger design and integrity of the software, yes, but they also need to communicate effectively with the development team, ensure the design is understood, coach a bit on the parts that are less common or are not part of the usual way the team is used to working, etc. To have the architect tied to deliverables necessarily means other things will not get the focus they should.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-8509343272562195687.post-13169364442536233252016-02-24T08:39:08.537-08:002016-02-24T08:39:08.537-08:00Then I also met QA guys unable to do their job bec...Then I also met QA guys unable to do their job because they were hired as non coders.<br /><br /><br />I could point that recently to break the resistance of coders to code stuff that don't work, more and more important coding decision with "added value" or "firctions" from the job of coders have been deported to non coders. <br /><br />Such as project management, business analyst, product managers, Human Resources, even boss. People that lead the work of skilled coders are not themselves coders taking decision without the experimental knowledge of cost and feasibility. Which seems to be the only true knowledge that betters software cost estimation hence pricing and costing. Hence should lead cost efficient business decisions. <br /><br />Having people steal our jobs without skills sure hurt the whole business. <br /><br />But in the first place it hurts even more to deny the true nature of creation that is both hard to make work and which benefits of the creation are given as an incentive to fools who can just need to capture more coders (designers, redactors, journalists, event organizer) and squeeze them like lemons to make more money. <br /><br />Our market is rigged by IP and it makes very counter productive systems. The regulations creates this unstable equilibrium by favouring the capital over the craftsman. <br /><br />Even amongst coders: they are the ones who get their legitimity by experience others by expensive diploma even though CS diploma are still not correlated to any proof of indeed producing better (or worst) coders. <br /><br />Regulations and perverted macro economical effects are affecting locally our work organization and it is proving to be having an adverse effect. <br /><br />It is time we face the truth: this is a clear effect of the intellectual property economy.<br /><br />Giving the benefits and the authority of the works not to those who know their jobs (praxis) but to those who to know to make benefits out of it (doxein). <br /><br />Hence the world used to be describing pro-net-arians could be crafted on this solemn occasion to describe this.<br /><br />And this does not apply to coders only, it apply hence for the heart of the who "service" economy. <br /><br />And that is the ugly secret behind our modern crisis. Giving the incentive to create working innovative business models to those who have interest in conservatism and lack of disruption.<br /><br />This is the pro-net-arisation of the web. julhttps://www.blogger.com/profile/06120175983940571527noreply@blogger.comtag:blogger.com,1999:blog-8509343272562195687.post-69333720892174883292016-02-24T06:12:22.766-08:002016-02-24T06:12:22.766-08:00May I add that architects should code along _with_...May I add that architects should code along _with_ the team implementing the project, not outside of it. More than half the code of our projects nowadays is non-production : unit, functional and stress tests, deployment, management. It's easy to ignore those aspects if you're coding alone towards a solution. But such code doesnt have much value if it doesnt have the support harness to guarantee trouble-free maintenance over its lifetime.Anonymoushttps://www.blogger.com/profile/15194167414234911557noreply@blogger.com