A friend of mine recommended this text on why programmers work at night. Entertaining but still true.
But the blog post referenced another interesting text written by Paul Graham about the necessity of holding a program in one’s head to be an outstanding programmer. I couldn’t agree more with that he says. I also agree with the corollaries that it is detrimental to treat developers as interchangeable parts in an organisation.
But what got me thinking was the fact that an architect must keep an entire system in the head. Where the programmer has the code as something tangible to base this mental model upon the architect has at best an abstract model and at worst only her own internal representation.
So for an architecture to be successful it both seems to be necessary that there is somebody who has the ability to internalise and reason about an entire system, and that the mental representation is possible to grasp in it’s entirety with (at least) one single mind. There are probably a lot of systems out there that fulfils neither….
Saturday, December 17, 2011
Monday, December 12, 2011
List of ECU functions to determine
List of ECU functions to determine
• fuel delivery • transmission shift points • valve timing • ignition timing, etc. sensors also monitor • oxygen levels of inlet air • oxygen levels of exhaust air • temperatures of inlet air • temperatures of exhaust • temperatures of oil • temperatures of coolant • temperatures of all other fluids like brake, clutch, transmission etc • sensors also monitors and controls functions of features such as ABS, EBD, EPS, ESP, SRS (airbags), etc. whichever applicable.
• fuel delivery • transmission shift points • valve timing • ignition timing, etc. sensors also monitor • oxygen levels of inlet air • oxygen levels of exhaust air • temperatures of inlet air • temperatures of exhaust • temperatures of oil • temperatures of coolant • temperatures of all other fluids like brake, clutch, transmission etc • sensors also monitors and controls functions of features such as ABS, EBD, EPS, ESP, SRS (airbags), etc. whichever applicable.
Monday, November 21, 2011
More on-line lectures on software architecture
I was discussing with one of my colleagues at the department if there were any introductory or summary presentations on-line about software architecture. I have already listed some on-line lectures about software archtiecture in the blog, but a quick search revelad some interesting ones:
- An Introduction to Software Architecture and the Risk-Centric Model by George Fairbanks. George is a an excellent lecturer and has written one of the best books available on software architecture. If you have the oportunity to discuss with him, take it. Too bad the sound is so bad in this video clip.
- Conscious Software Development: Architecture with Jeff Mckenna. Why not look through all parts in the series while you are at it?
- Software Architecture Document by Philippe Back. I don't know who this guy is, but he manages to convey a lot of essentials in 12 minutes
- SEI has a number of webinars related to software architecture. Unfortunately I can't get them to play on my computer, maybe you can?
- Out and About: Software Architecture with Simon Brown. A short clip with a view on what a developer needs to do to be an architect.
- Considering a Software Architect Career by Marc Ferrentino. A very short clip on what skills you need if becoming an architect.
Friday, November 18, 2011
MeeGo is out, what is in?
There has been some turmoil in the world of infotainment platforms. Intel has left Meego and have partnered with Samsung in Tizen. This just a few months after Meego 1.2 vas deemed GENIVI compliant. I have no idea if Tizen aims to be GENIVI compliant as well. But there are already some commercial platforms that are GENIVI compliant.
I have been involved in the Open Infotainment Labs, a project patially funded by VINNOVA aiming att evaluating radically different work methods compared to standard practice at most car manufacturers. We integrated the system in a car this week, 16 weeks after start of development.
I have been involved in the Open Infotainment Labs, a project patially funded by VINNOVA aiming att evaluating radically different work methods compared to standard practice at most car manufacturers. We integrated the system in a car this week, 16 weeks after start of development.
Sunday, November 13, 2011
AUTOSAR as open source
This might be the coolest thing I have seen so far: There exist an open source distributions of AUTOSAR!
And it's local to us here in Gothenburg, should I be embarassed for not hearing about this earlier?
Caveat: Note that if you intend to use AUTOSAR in a business setting you need to fulfill the conditions according to the AUTOSAR consortium.
After some e-mail exchange I now know that the open source AUTOSAR BSW software (ver 3.1) is available under a GPLv2-license.
And it's local to us here in Gothenburg, should I be embarassed for not hearing about this earlier?
Caveat: Note that if you intend to use AUTOSAR in a business setting you need to fulfill the conditions according to the AUTOSAR consortium.
After some e-mail exchange I now know that the open source AUTOSAR BSW software (ver 3.1) is available under a GPLv2-license.
Wednesday, October 26, 2011
Set-based architecture
I listened to a presentation from Durward K. Sobek II about set-based concurrent engineering, which is a development paradigm(?) from lean development (more precisely from Toyota Product Development System).
The original principle, as I understand it, is that a designer should work with a set of design proposals towards manufacturing and in the dialogue between what is desirable (form engineering) to what is possible (from manufacturing) iteratively narrow it down to a single design. He concluded the presentation with how one would start with this in the small and the advice was to present two designs instead of a single one the next time
It made me thinking about how an architecture is “presented” to the stakeholders, especially the developers. would it be possible to present two architecture proposals to developers and let them identify the constraints from their perspective in narrowing it down to a single, agreed, architecture.
Thursday, October 6, 2011
Choke on cinnamon buns?
I wrote in a previous blog post about that I get upset about bad programming. I stumbled upon a prime example of bad programming from the excellent website Jävla skitsystem on that it was not possible to buy 20 identical cinnamon buns at 7-eleven at the same time because it crashes the cashier system and it would take 15 minutes to reboot.
I don't know what is most stupid? That there is an actual limit on the amount of goods you can buy, that the system crashes without recovery if you pass this limit or the fact that it takes 15 minutes (!) to reboot. First I cannot understand that the programmer was so narrow-minded he/she could not imagine these situations. Second I don't understand that the company delivering the system did not catch this in their testing. What kind of procedures do they have? And this system handles money...
I don't know what is most stupid? That there is an actual limit on the amount of goods you can buy, that the system crashes without recovery if you pass this limit or the fact that it takes 15 minutes (!) to reboot. First I cannot understand that the programmer was so narrow-minded he/she could not imagine these situations. Second I don't understand that the company delivering the system did not catch this in their testing. What kind of procedures do they have? And this system handles money...
Tuesday, October 4, 2011
First International Software Technology Exchange Workshop
Swedsoft arranges a workshop in Stockholm on Wednesday 23 Novemeber. It is dedicated to transfer academic results to industry. Sounds really interesting.
First International Software Technology Exchange Workshop 2011
First International Software Technology Exchange Workshop 2011
Tuesday, September 27, 2011
The angry programmer?
My wife thinks I should start another blog named "Ulriks programming nightmares". Or maybe just add another topic of this blog where I mention examples of programmed systems that aren't good. Or to be more precise, where the programmer was too lazy to do a good job, which really gets me going. Unfortunately I get upset when I see it among the students which is a bit harsh, they are here to learn after all.
The examples I have seen so far is everything from the logic of the elevators at the university to how the booking system of SJ places people at a train. Seriously, if there are 3 reserved seats in a wagon, why must two of them be next to each other?
Enough ranting, but is this a good idea to expand the topic of the blog with? Coming to think of it, there must already be sites like that out there. If not there should be, it is always more educational to learn from bad examples than good.
The examples I have seen so far is everything from the logic of the elevators at the university to how the booking system of SJ places people at a train. Seriously, if there are 3 reserved seats in a wagon, why must two of them be next to each other?
Enough ranting, but is this a good idea to expand the topic of the blog with? Coming to think of it, there must already be sites like that out there. If not there should be, it is always more educational to learn from bad examples than good.
Documentation
When it comes to documentation I am firm believer in the quote of Antoine de Saint-Exupery:
“A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away.”
As I see it there are a few main purposes of producing documentation:
To convey understanding - This shows my quite liberal view of documentation since I consider drawings on a white board or a napkin to be documentation. But I also consider this to be one of the most important purposes of documenting things. From a designer’s viewpoint these “documents” are vital in going from an inner vision to an operational image that can be shared by others. Common examples of documentation conveying understanding in large organisations are presentations given at various meetings. These documents can be saved for posterity, but the ability to convey understanding is much smaller for those who weren’t there. On the other hand are written documents one of the most efficient means through history to build on knowledge of others which you never had the opportunity to meet.
To formalise agreements – If there is a business agreement between two organisations it is almost inevitable not to have a more formal document detailing the technical content of the agreement, the specification. many organisations, including my own, also use documents to formalise the agreement between internal teams. Your mileage may vary how efficient this is in various organisation.
To preserve information – The human memory is not infallible. Documentation is a great support to minimise the decay that is inevitable when only relying on the human mind. Software is also about maintenance and any body who has been given the responsibility to update legacy code that is undocumented know how difficult it is (this scenario includes the purpose of understanding as well)
I don’t buy “the code is the documentation” at all. The code by itself does not fulfil any of the purposes above.
I have recently worked in a project which solely relied on Trac to capture all information relevant to the project (except finances). I am positively surprised how much you can achieve with so little formal documentation in combination with having everything in the same place available for everybody in the project. I will try to do a more formal evaluation according to the purposes above when the project is near it’s end.
Tuesday, September 20, 2011
When to decide?
I have recently experienced several occasions where people want to decide things as early as possible in a project. This seems to be based on previous experiences that this was difficult in the last project and we want to eliminate things to worry about late in the project since there will be new things to worry about then anyway. So why not solve the major problems you are aware about anyway?
I think this kind of thinking is detrimental for the success of the project, especially if the decision influences the architecture (Grady Booch said something like "the architectural decisions are those costly to change").
If one looks at the reason the problems came up in the first place it is usually things like the implications (especially technical) of the decisions was not fully understood, the requirements were not suitable, or my personal nightmare that my team will not suffer any consequences whatever the outcome so why not decide this now...
If one has superficial understanding of the consequences or if the requirements are unstable it is a better strategy to postpone the decision as late as possible, and also delegate it to those who are most affected/concerned. But this means you and your organisation is comfortable with living with uncertainty. Which may be very difficult depending on the culture or the organisation. For example if all of your project revolves around a stage-gate process (very common in the automotive industry) it really does not fly well to say "let's postpone this decision for another 6 months and make progress with what we can".
It may sound I ampreaching the agility gospel, but that is not the case. I have full understanding that once you have made an architectural decision you don't want to change it. I just want to argue for the heuristic that you should not decide something because you can, postpone it to when you have make it.
And as a consequence I really dislike when you have to decide things just to feed the process, especially if the process is very slow to change.
I think this kind of thinking is detrimental for the success of the project, especially if the decision influences the architecture (Grady Booch said something like "the architectural decisions are those costly to change").
If one looks at the reason the problems came up in the first place it is usually things like the implications (especially technical) of the decisions was not fully understood, the requirements were not suitable, or my personal nightmare that my team will not suffer any consequences whatever the outcome so why not decide this now...
If one has superficial understanding of the consequences or if the requirements are unstable it is a better strategy to postpone the decision as late as possible, and also delegate it to those who are most affected/concerned. But this means you and your organisation is comfortable with living with uncertainty. Which may be very difficult depending on the culture or the organisation. For example if all of your project revolves around a stage-gate process (very common in the automotive industry) it really does not fly well to say "let's postpone this decision for another 6 months and make progress with what we can".
It may sound I ampreaching the agility gospel, but that is not the case. I have full understanding that once you have made an architectural decision you don't want to change it. I just want to argue for the heuristic that you should not decide something because you can, postpone it to when you have make it.
And as a consequence I really dislike when you have to decide things just to feed the process, especially if the process is very slow to change.
Friday, August 19, 2011
Formula 1 2011 Australian Grand Prix (2011)
Formula 1 2011 Australian Grand Prix (2011)
The 2011 Formula 1 TM Qantas Australian event is the country's most spectacular sporting event and will feature an impressive array of both on-track and off-track activities for people of all ages to enjoy. If you've never experienced the thrill of a Formula 1 TM car racing by at speeds of more than 300 km/h, make 2011 your opportunity to witness this unforgettable phenomenon.
Just Click This Link To Redirect Putlocker Source
Just Click This Link To Redirect Sockshare Source
The 2011 Formula 1 TM Qantas Australian event is the country's most spectacular sporting event and will feature an impressive array of both on-track and off-track activities for people of all ages to enjoy. If you've never experienced the thrill of a Formula 1 TM car racing by at speeds of more than 300 km/h, make 2011 your opportunity to witness this unforgettable phenomenon.
Just Click This Link To Redirect Putlocker Source
Just Click This Link To Redirect Sockshare Source
Friday, July 8, 2011
Thursday, July 7, 2011
Thursday, June 30, 2011
WICSA 2011
I was at WICSA last week. I am a lousy trendspotter, but here is what I have seen as “trends” so far:
There seems to be several efforts, especially on the tool side, that focuses on capturing and navigating architectural information. Is this a sign that architecture information is getting bigger and bigger and is distributed among different sources/artefacts? I thought one of the tangible deliverables from an architect was a comprehensive documentation/model/wiki/whatever with architecture information. As a contrast there wa a tutorial the last day by George Fairbanks on writing a 1-page architecture document. I would say this was a highlight of the conference, to bad most people had gone home by then.
In general it seems architects are more aware of the need to adopt to agile development. I don’t think there is any contradiction, contrary I believe that it is necessary for agile developers to be more aware of “architectural thinking” and what benefits there is of having an explicitly defined architecture. But I do agree that often architecture is the same as Big Upfront Design. At the panel debate I understood better the historical background; many of the originators of the agile manifesto were active developers already in the late eighties and nineties when a lot of focus where on software design. people who started as developers in the last decade don’t have that background and think that the last years focus on process is all that is necessary for developing good software.
There was some discussions on architecture-based testing (this is a good strategy to define a new research area, combine two or more buzzwords), but it was confusing. some people seemed to mean an architecture where it was easy to verify the quality attributes it was designed to achieve. others seemed to mean an architecture for a systems that was easy to test for testers. I like the latter better, and hope there will emerge more patterns for this than the general patterns of encapsulation etc.
Compared to the last WICSA in 2009 I think the acceptance rate was much higher, above 40%. I think this could be one explanation to why some papers had a rather weak scientific methodology. One other thing I did not like at all were some studies based on industrial practice where the results were too polished. if you present a case study you should include all the small (and big) problems that occur in real settings, otherwise the cases are not of more interest than textbook examples.
Tuesday, June 28, 2011
Smoke 'm if you got them.
The "riders vice" tagline tells me that Pirelli tires are being associated to cigarette, a really bad message. Interesting antagonistic move, but does not make me want to buy Pirelli's tires.
Advertising Agency: Y&R, Milan, Italy
Via: adsora.com
Advertising Agency: Y&R, Milan, Italy
Via: adsora.com
Yamaha scooter advertising campaign - Costa Rica
Some make a jungle of the road. You are better off buying a scooter and receiving a free driving course.
Advertising Agency: Smart, San José, Costa Rica / Creative Director: Marco A. Castro.
Via: adsora.com
Advertising Agency: Smart, San José, Costa Rica / Creative Director: Marco A. Castro.
Via: adsora.com
Monday, June 27, 2011
Classic Endurance Racing, Spa Francochamps Belgium 2011
Classic 4 wheeled mechanical beauties.
Play in full screen with volume at max.
CER 1 - GT´s 1966 / 1974 & Prototypes 1966 / 1972
See and hear motor legends as Lola T70, Ford GT40, Chevron B16, Plymouth Barracuda, Porsche 906, Porsche 910 and the unique Howmet TX Turbine car.
For more classic car racing videos: motorsportvideo.tv
Play in full screen with volume at max.
CER 1 - GT´s 1966 / 1974 & Prototypes 1966 / 1972
See and hear motor legends as Lola T70, Ford GT40, Chevron B16, Plymouth Barracuda, Porsche 906, Porsche 910 and the unique Howmet TX Turbine car.
For more classic car racing videos: motorsportvideo.tv
SIDEBURN magazine - 'ROOSTER' a film by Drogo Michie
Rooster from SIDEBURN on Vimeo.
SIDEBURN magazine presents 'ROOSTER' a short film by Drogo Michie.
Shot at Sandy Lane speedway, Oxford England
sideburnmagazine.com
Little road movie with French veteran motorcycles
Little road movie by the Vintage motorcycle club ADAM, France.
Motorcycles: terrot 350, peugeot p107, favor 350, magnat debon 350, monet goyon 350, motobecane 125, automoto 350, gima125
Sunday, June 26, 2011
Saturday, June 25, 2011
Subscribe to:
Posts (Atom)